Любой рынок постоянно развивается, и безопасность здесь не является исключением. Но, к сожалению, в нашей стране (да и в остальном мире, но в меньшей степени, я думаю..) забывают о реальном обеспечении защиты сводя все к покупке продуктов вроде файрволла или очередной VPN-системы, а также созданию политик безопасности и регламентов..
В наше время информационная безопасность является одним из ключевых аспектов,
необходимых для непрерывного и успешного ведения современного бизнеса. Рынок
информационной безопасности как в нашей стране, так и во всем мире очень быстро
и успешно развивается в нескольких различных направлениях. Как правило, это либо
разработка специального ПО для защиты (например файрволлы, VPN-системы,
антивирусы,  SPAM-фильтры и пр.), либо предоставление специализированных услуг
(вроде анализа рисков компании и разработки политики информационной
безопасности). Но, к сожалению, вся индустрия очень часто забывает о такой вещи,
как 0-day уязвимости и приватные эксплоиты, которые постоянно появляются в
соответствующих
неофициальных кругах, а также используются и покупаются уже более
заинтересованными лицами. В первой части моего материла я хотел бы ввести вас в
курс дела, описав основные фундаментальные атаки на компьютерные системы, а
также способы обхода защит, созданных специалистами по безопасности.
Итак, давайте определимся, какие атаки представляют собой главную опасность
для программного обеспечения (и разумеется для ОС, на которой установлено данное
ПО) – это атаки переполнения буффера (в стеке и хипе), ошибки форматной строки,
целочисленные переполнения, а также другие уязвимости, которые мы опишем
подробнее
в следующих разделах. Это те вещи, которые грамотные разработчики постоянно
ищут в своем коде, это то, что является причиной 99% всех Advisory (уведомлений,
касающихся безопасности) – те патчи, которые приходиться устанавливать системным
администраторам чуть ли не каждый день. Но предположим такой вариант, что хакер
нашел уязвимость раньше разработчика (такое случается постоянно, хотя бы потому,
что у разработчика полно других забот). Как правило, он разрабатывает эксплоит –
специальный код, которых использует конкретную уязвимость. По вашему этот
эксплоит он немедленно отправит в BugTraq и разработчики, проанализировав код,
выпустят соответствующую заплатку? Уверяю вас, времена full-disclosure (полного
разглашения информации) уже давно прошли, как и времена различных
security-team’ов, которые занимались подобной практикой. Те, кто остались, либо
ушли на работу в коммерческие организации, либо в глубокий андеграунд.. Как
правило, первые не занимаются подобными вещами, а вот вторые не только продают
подобный “warez” в чистом виде, но и активно его используют (к примеру для
создания ботнетов, организации DDoS атак, рассылки спама, а также для других
более утонченных и комплексных проектов). И увы, тут не помогут не новейшие
файрволлы и антивирусы, ни системы анализа защищенности – от подобных атак не
могут защитить стандартные средства, здесь нужен другой подход. Но прежде чем
обсуждать возможные варианты защиты, давайте подробнее остановимся на этих
атаках.
Это самый старый и известный метод, котором пользуются люди, которые ищут
ошибки в ПО и пишут эксплоиты. Проблема состоит в функциях, которые не проверяют
границ (например strcpy(), gets(), strcat(), scanf(), fscanf(), getwd() и пр,
если применительно к C/C++). Из за этого мы можем выйти за границы массива
(группа данных идентичного типа) и изменить важные значения, сохраненные в
стеке, в том числе EIP – адрес возврата (это место, куда программа передает
управление после выхода из функции) скажем на адрес нашего шеллкода (машинный
код, которые выполняет нужные нам действия, чаще всего это запуск интерпретатора
командной строки). Итак, давайте на примере посмотрим как данные некой функции
располагаются в стеке, используя классический strcpy баг:
После загрузки программы в виртуальную память, стек будет выглядеть так:
Итак, мы контролируем msg, буффер buf фиксированного размера (80 байтов, но в
реальности компилятор может выделить немного больше пространства). Функция
strcpy не проверяет границ, поэтому мы можем переписать все за buf, включая
сохраненный адрес возврата в стеке, как это видно на схеме. Проверим:
Как видите, программа пыталась выполнить инструкцию по несуществующему адресу
0x41414141 (41 in hex = A), то есть мы полностью контролируем значение адреса
возврата (регистра EIP) и можем заставить программу выполнить любые действия.
Конечно, существуют различные вариации на тему написания эксплоитов
переполнения буффера, так как методы эксплоитинга stack-based переполнений очень
сильно эволюционировали (nops+sc, eggshell, Murat Balaban method, ret-to-func и
тд.). Но для нас, как правило, это не играет большой роли.
Данные атаки не так хорошо изучены и описаны, по сравнению со stack overflow,
но, тем не менее, широко распространены. Для хранения очень больших объемов
данных часто используют heap – специальную область памяти, которая, в отличие от
стека, растет вверх. В heap-based переполнении мы можем переписать указатели
(например, указатель на файл – подставить туда свое значение, допустим
/etc/shadow и если процесс запущен под рутом, то мы увидим содержимое этого
файла), указатели на функции (к примеру, заменить адрес функции на адрес нашего
шеллкода) и пр. Проблема все та же – использование небезопасных функций,
отсутствие проверки границ, исполняемый heap.. Рассмотрим простой пример
heap-based переполнения (используется Doug Lea’s Malloc) :
У нас не получается стандартного переполнения, так как происходит вызов
функции free(), которая пытается освободить память по адресу 0x41414141,
естественно такого адреса просто не существует и программа успешно падает. Чтобы
обмануть free(), нам надо просто подставить ей любой валидный адрес в heap
пространстве, проверим:
Мы передали free() адрес в хипе, который она успешно освободила (к слову
сказать, это адрес ptr в heap – во избежание лишних проблем мы передали именно
этот адрес), и после выхода из функции соответственно передала управление
адресу, который мы полностью контролируем. Есть еще очень много различных
способов, вариантов и возможностей использования и эксплоитирования heap-based
переполнений. Эти ошибки довольно распространены и дополнительная (и наверное,
главная) сложность состоит в том, что такие ошибки очень сложно отлавливать на
уровне кода – то есть, потенциально, их очень много.
Ошибки данного класса появились из-за особенностей реализации функций
семейства printf (и им подобных). Проблема в том, что если не указан
спецификатор формата, пользователь может сам его указать, а значения система
будет брать из стека (с вершины). Более того, есть спецификатор %n, который
позволяет записать определенное значение по заданному адресу (что и позволяет
нам выполнять произвольный код)! Рассмотрим небольшой пример уязвимой программы:
Как видите, мы добрались до массива stack.
При определенных условиях, мы можем изменить процесс выполнения
программы, то есть заставить ее выполнить некий условный код по
нашему адресу, используя все тот же спецификатор “%n”, цель стандартная –
перевести управление на наш вредоносный код. Про “банальный” DoS ala “%s” x
100 я упоминать не буду. Однако успокаивает то, что подобные ошибки довольно
легко отлавливать автоматизированными средствами, но это не касается функций,
которые написали программисты специально для своего ПО..
Это самый новый способ из описываемых мною фундаментальных атак, который
очень
быстро набирает обороты. Переменные с типом int – это область в памяти (как
правило, 32 или 64 бита), предназначенная для хранения некого целочисленного
значения. Целочисленное переполнение – это выход за пределы допустимого
значения, если в переполнении к примеру стека играет роль размер массива, то
здесь имеет значение максимальное число, которое может храниться в переменной. В
некоторых случаях мы можем  влиять на процесс выполнения программы. Давайте
рассмотрим пример:
На первый взгляд программа должна работать нормально, проверим:
Но что будет, если мы попытаемся переполнить i ?
Дело в том, что размер аргумента копируется в b, а потом “переносится”
в a, в котором не хватает места для числа (тип short). Из-за этого мы
проходим проверку. После этого могут быть использованы стандартные методы
(вроде
переполнения стека). И хотя целочисленные переполнения в чистом виде почти не
предоставляют угрозы, тем не менее, они иногда позволяют провести другие
атаки, вроде переполнения стека или использование ошибок форматной строки.
Хотелось бы заметить, что сейчас появились способы детектирования целочисленного
переполнения. Возможно, в скором времени подобные проверки будут встроены в
компиляторы.
Other techniques and code problems..
Существуют также несколько других общеизвестных проблем и техник, и я вкратце
опишу их.
Return-to-Func (Return-into-Libc) – как правило,
используется для обхода систем с  неисполняемым (non-executable) стеком. Суть
работы довольно проста – поскольку мы не можем выполнить код в стеке, мы
“возвращаемся” не в стек, а в область памяти, используемую общими библиотеками.
К примеру, мы можем переписать EIP на адрес функции system(), передав дальше
аргументы (/bin/sh, например). Поскольку никакого кода в самом стеке не будет
выполняться, мы успешно получаем оболочку (если переписываем на system() и
указателем на /bin/sh в качестве  аргумента, разумеется). С этим как правило
борются наличием null-байтов в адресах функций, а также рандомизацией их адресов
(подобные способы реализованы в некоторых средствах защиты).
Frame pointer overflow – это атака, при которой мы
можем переполнить наш буффер всего лишь на один байт. При определенных условиях
мы можем выполнить произвольный код. Идея состоит в том, что мы в состоянии
переписать 1 байт в EBP. После выхода из функции регистр EBP будет скопирован в
ESP, то есть мы можем изменять регистр произвольным значением (не совсем
произвольным, так как нам доступен для перезаписи только один байт). Итак, вот
“псевдокод”, это конец функции main():
То есть программа копирует EBP в ESP и выполняет инструкции по адресу,
который находится в стеке (ret) – на что указывает ESP.
Adj overflow (adjancent memory overflow) – это
последствия особенностей
реализации некоторых функций. Многие функции находят конец строки
по null байту (0x00), но что если строка у нас такого же размера, как и
буффер?
NULL-байт просто не будет записан! Рассмотрим пример:
Итак, вопрос: Может ли buff3 переполнить buff1? Может! Если
buff3 не будет завершен NULL байтом, то sprintf будет продолжать
копирование, пока не встретит этот null-byte, а вот и последствия:
Мы можем изменить процесс выполнения программы.. Как видите, при определенных
условиях так можно эксплоитировать функцию strncpy (“безопасная” замена strcpy,
с проверкой границ) и не только ее. Однако стоит отметить, что данная атака
требует множество условий.
Как я уже говорил, шеллкод – это машинный код, как правило локально
вызывающий
оболочку или привязывающий ее к сокету (используется для удаленных
эксплоитов). Есть еще много различных типов шеллкодов, это reverse-conected
шеллкоды (как правило, используются для обхода файрволлов и других фильтров
сетевого траффика), полиморфные шеллкоды (используются для обхода систем
обнаружения вторжений), architecture spanning шеллкоды (это машинный код,
который будет успешно работать на различных архитектурах, например на SPARC и на
Intel, это повышает универсальность шеллкода), alphanumeric и unicode шеллкоды
(используются для обхода фильтров на различные символы в приложениях) и тд, все
это очень большая, интересная и сложная тема. Вот пример простого
execve-шеллкода (под ОС Linux):
Данный машинный код выполняет /bin/sh (linux x86). Тонкости работы кода нас
не сильно интересуют, нам лишь важно знать, что шеллкод используется в 95%
эксплоитов, и при удачной атаке на него передается управление и он, разумеется,
выполняется. Работа шеллкода составляет главную и ключевую роль практически в
любом эксплоите. Вот вы и познакомились с фундаментальными атаками, теперь
давайте немного рассмотрим системы защиты, созданные специалистами по
безопасности.
Суть работы этих программ довольно проста – StackGuard записывает canary
(специальное
псевдослучайное значение) между сохраненным адресом возврата и
EBP. Если значение canary изменилось, то это событие квалифицируется как
атака на переполнение буффера. StackShield действует иначе – он создает
специальное пространство retarray для хранения копии адреса возврата. После
выхода из функции этот адрес копируется в EIP. Каким бы безопасным это не
казалось на первый взгляд, существует по крайней мере несколько способов обхода
данных средств защиты. Во первых, нам не обязательно переписывать canary, если
мы можем воздействовать на указатель – переписать его на адрес возврата, а потом
попросту заменить его на шеллкод, то есть если есть такой псевдокод:
Естественно, предполагается что “a” – контролируемый нами указатель.
Хотя, конечно, успех атаки зависит от кода функции, что естественно
очень сильно снижает риски.. Но есть другие способы, например,
немного изменить Global Offset Table (GOT), скажем, вот в таком коде:
нам надо переписать GOT printf() на адрес system(), в результате программа
выполнит system(“and after second strcpy..
“);
и все что нам теперь нужно – это создать скрипт “and” в нашей директории,
который и запустит программа.. Или, например, если программа вызывает функцию
exit() (разумеется, у нас по прежнему должен иметься в наличии указатель,
которым мы можем манипулировать), мы можем переписать адреса функций в структуре
fnlist на адрес нашего шеллкода. Это лишь часть найденных способов обхода
подобных защит. Данные программы сейчас уже практически нигде не используются,
но надо отдать им должное, так как многие современные системы защиты используют
представленные авторами этих продуктов техники.
В операционной системы Microsoft Windows 2003 встроена защита от переполнения
стека.
Она заключается в следующем – за адресом возврата (который сохраняется в
стеке, чтобы программа знала куда обращаться после выхода из функции) кладется
специальное число (canary, cookie..). Если мы попытаемся переписать адрес
возврата, соответственно, изменим canary и выполнение процесса прекратится (вы
не находите сходства со StackGuard?). Но существует несколько способов обхода
подобной защиты, нацеленных не на архитектурную составляющую защиты в целом и не
на особенности реализации уязвимых функций в эксплуатируемом ПО, а именно на ее
реализацию специалистами софтверного гиганта. Если cookie не совпадает с
оригинальным значением, который хранится в секции .data, то выполняется
специальный security-handler, который тоже хранится в секции .data. Если никакой
обработчик (handler) не задан, тогда UnhandledExceptionFilter устанавливается на
0x00000000 и выполняется функция UnhandledExceptionFilter – которая в свою
очередь загружает в общую память библиотеку faultrep.dll и вызывает функцию
ReportFault (это то самое всплывающее окно, которое просит вас отправить отчет о
ошибке в Microsoft). Стоит заметить, что в ОС Windows существуют обработчики
исключений, которые помогают программистам делать приложения более стабильными,
если происходит какое-то непредвиденное действие, например попытка записи в
read-only память, для такого действия может быть написано исключение, которое в
последствии может “реанимировать” процесс. Дело в том, что в каждом потоке
процесса существует как минимум один обработчик, информация о нем хранится в
стеке, в структуре EXCEPTION_REGISTRATION, которая имеет два элемента –
указатель на следующую структуру EXCEPTION_REGISTRATION и указатель на
обработчик исключений, который мы не можем просто переписать – так как теперь
все адреса обработчиков исключений зарегистрированы и хранятся в Load
Configuration Directory. То есть, прежде чем выполнить обработчик по некому
адресу, он сверяется со списком зарегистрированных обработчиков и не будет
выполнен, если не будет там найден. Но стоит заметить, если адрес обработчика
находится за пределами адресного пространства загруженного модуля, то это адрес
БУДЕТ выполнен! Также если адрес находится в области heap – он будет выполнен
тоже, хотя, если адрес будет в области стека, по понятным причинам он выполнен
не будет. Итак, нам надо сгенерировать исключение, например, попытаться что-то
записать за пределами стека.
Это вызовет исключение. Теперь остается только переписать указатель на
обработчик
адресом вне адресного пространства загруженного модуля, он будет проверен со
списком зарегистрированных исключений, но поскольку адрес находится вне
адресного пространства, ему будет передано управление. Теперь атакующему
остается лишь найти блок инструкций вне адресного пространства, который
переведет управление на область в памяти, которую контролирует атакующий (то
есть в область, в которую он может “загрузить” шеллкод). Как вариант можно еще
(если это позволяет эксплуатируемый код) “загрузить” шеллкод в буффер, который
находится в хипе (heap) и переписать указатель обработчика на адрес буффера в
heap пространстве.
С течением времени Microsoft решила усовершенствовать свою защиту, обратив
внимание на область хипа (heap). Однако, к сожалению, надежды не увенчались
успехом
(увы, но такое часто случается..). Существует как минимум несколько различных
способов противодействия защите, встроенной в пакет обновлений Service Pack 2
операционной системы Windows XP. Итак, чтобы обезопасить себя от переполнений, в
систему менеджмента хипа было добавлено две проверки чанков (chunk’s) – во
первых, это проверка cookie в заголовке чанка, а во вторых, довольно эффективная
проверка указателей Flink и Blink (это указатели на следующий и предыдущий
свободные блоки соответственно). На мой взгляд, наиболее предпочтительный метод
обхода защиты заключается в следующем – многие API-функции хранят некоторые
данные загруженных библиотек (DLL) в хипе, то есть еще до старта main(), в хипе
уже создано несколько чанков, как правило их структура выглядит так:
где A и B – адреса следующей и предыдущей структур соответственно и если мы
сможем их заменить, то будем в состоянии переписать произвольные 4 байта в
памяти (например, адрес возврата). Эта атака возможна потому, что не происходит
никакой проверки указателей на структуры (A и B)! Также существует другой метод,
который предложил наш соотечественник, Александр Анисимов, связанный с атакой на
ассоциативные массивы, так как в них тоже не проводится никаких специальных
проверок, но такой метод довольно сложно применить на практике. Последствия –
возможность переписать произвольные 1016 байтов в памяти.
Рынок информационной безопасности потихоньку стал немного присматриваться
к защите от переполнения буффера, встраивая защитные механизмы в свои HIPS
(Host Intrusion Prevention Systems), которые, помимо всех прочих возможностей
(противодействие spyware/adware, встроенный файрволл, аудит различных событий и
пр), содержат так называемую технологию Stack Backtracing, которая позволяет проводить перехват и анализ функций на наличие шеллкода и соответственно
запрещать вызовы при наличии такового (как ни странно, в этом содержится своя
слабость –
эти продукты не предотвращают атаки переполнения буффера в принципе, то есть
не создают неисполняемые стек и хип, а лишь пытаются перехватить шеллкод в
вызываемых (читай перехватываемых) API-функциях). Первая проблема состоит в том,
что шеллкод может детектировать функции, которые перехватываются. Защитные
механизмы в обычную преамбулу функции (push ebp; mov ebp, esp) добавляют call
или jmp и для шеллкода не составит труда обнаружить данную “сигнатуру”. После
успешного детектирования шеллкод может обойти систему защиты, например, вставить
свою копию преамбулы, а потом перевести управление сразу после API-хука. Но
самый универсальный способ, который действует как против перехвата функций на
уровне пользователя (ring3), так и на уровне ядра (ring0) – это подделка stack
фреймов, то есть шеллкоду надо создать поддельный stack фрейм без ebp в стеке. А
поскольку техника stack backtracing зависит от наличия ebp в стеке, чтобы найти
следующий stack-фрейм, поддельный фрейм может остановить stack backtracing.
Итак, нам всего лишь надо создать stack-frame с верным адресом возврата, который
указывает на read-only область памяти.
Кроме того, надо заметить, что перехват API-функций на уровне пользователя
несет в себе кучу проблем. Во первых, необходимо перехватывать и анализировать
ВСЕ функции, которые может использовать атакующий (например, NAI Entercept 4.1
перехватывает LoadLibraryA, но ничего не знает о LoadLibraryW). Во вторых,
некоторые продукты перехватывают функции только в kernel32.dll, забывая при этом
о ntdll.dll, это недоработка все в том же NAI Entercept. Также существуют
способы обхода многих других средств защиты, например Open Wall (патч нашего
соотечественника Александра Песляка, более известного как Solar Designer),
GrSecurity, обход DEP (как софтверного, так и хардварного) и тд. Я думаю,
достаточно. Главное, чтобы вы уловили суть и идеи атак и защитных механизмов, а
также некоторые способы их обхода (некоторые продукты уже устранили описанные
уязвимости, некоторые нет..).
Итак, после всего прочитанного вы твердо решили серьезно повысить
безопасность своих систем. С чего начать? Я выделил несколько этапов активной
защиты. Во первых, полезная нагрузка эксплоита (payload) пройдет множество
систем по определенному маршруту. Поэтому очень важно, чтобы наш сервер
“прикрывал” пограничный маршрутизатор и/или файрволл с установленной и правильно
настроенной системой обнаружения/предотвращения атак (а еще лучше, если подобная
система будет стоять на самом “target” хосте, если это позволяет
производительность машины). Давайте подробнее рассмотрим методы защиты, которые
применяются в современных системах обнаружения вторжений. Главный бастион – это
сигнатуры (определенная последовательность байтов в пакете, которая
соответствует некоторому действию, например, попытки эксплоитации RADIUS
ATTR_TYPE_STR). Многие IDS имеют базу данных сигнатур, которые включают в себя
детектирование совершенно различных действий – сканирование портов, попытки
определения операционной системы (OS fingerprinting), попытки DDoS’а и пр. Но
самое интересное для нас – это блокирование атак и детектирование/перехват
шеллкодов. Эксплоиты (разумеется, уже существующие) перехватываются по
определенным особенностям. Вот, например, пример сигнатуры для эксплоита под
kadmind у IDS Snort:
Это означает, что если tcp-пакет с любым адресом источника попытается
достучаться до IP-адресов, которые содержатся в $HOME_NET по 751 порту и будет
содержать в себе определенный объектный код, который представлен в
шестнадцатеричном виде, то система обнаружения вторжений квалифицирует данное
событие как попытку эксплоитинга BOF в kadmind. Хотя, на мой взгляд,
блокирование эксплоитов по сигнатурам приносит сомнительную пользу (лишняя трата
времени, не находите? Хотя..).. Более интересная часть – это детектирование и
перехват шеллкодов. Достигается это теми же сигнатурами, которые содержат в себе
часто используемые шеллкодами байты и функции (последовательности байтов). К
примеру, все в том же IDS Snort есть препроцессор fnord, который даже пытается
определить полиморфные шеллкоды.
Самый примитивный метод – определять шеллкод по наличию NOP, то есть,
разумеется, не просто 0x90 (это No Operation для x86), а аналогичные по
функционалу операции вроде inc/dec, xchg %ebp,%ebp и пр, а также вариации nop-ов
для различных микро-процессоров. Можно “вытягивать” системные вызовы из
траффика, например setuid/setgid. Кроме того, есть много довольно интересных
дополнительных техник, которые активно используются некоторыми системами
обнаружения/предотвращения вторжений. Например, детектирование типичных
приглашений интерпретаторов командой строки (/bin/sh и cmd.exe). Не стоит и
говорить, что скажем перехват шеллкодов по различным “nop-like” сигнатурам очень
серьезно влияет на производительность машины. Конечно, в любом случае надо
пристально изучать используемую вами IDS систему, а лучше предварительно
проконсультироваться с поставщиком (главное, чтобы консультацию проводили
грамотные специалисты, а то в наше время могут преподнести “перехват” с десяток
не актуальных экплоитов по сигнатурам как 100% защиту от вредоносного кода.. это
печально, но вопрос здесь скорее к менеджерам компаний-распространителей IDS
систем). Второй (и бесспорно самый главный) бастион защиты – это используемая
вами локальная операционная система. Здесь надо рассматривать несколько
возможностей атаки. Мы сразу обратим внимание как на локальные атаки, то есть
когда у злоумышленника уже есть валидный аккаунт, так и на удаленные атаки,
учитывая, просто к примеру, что использовался какой-нибудь метод полиморфизма и
шеллкод все таки прошел через IDS/IPS фильтр. Давайте по порядку остановимся на
каждой атаке и составим необходимые общие рекомендации по защите.
Эксплоитирование уязвимости типа переполнения буффера в стеке (Stack Based
Overflow) поможет предотвратить неисполняемый стек, который сделает невозможным
выполнение шеллкода (да и любого другого кода) в стеке. Хотя, некоторым
приложениям это необходимо, но системы защиты придумали различные ухищрения,
чтобы бороться с этим ограничением. Но существует другая проблема – ret-to-func
(ret-into-libc) эксплоиты, которые с легкостью обходят подобную защиту, вызывая
функции из общей памяти и подставляя соответствующие аргументы. Но их проблема в
том, что они используют определенные “зашитые” адреса функций (вообще
использование каких-то определенных значений понижает универсальность эксплоита,
но во многих случаях это необходимо, точнее неизбежно..). Специалисты по
безопасности придумали средство против данной атаки – рандомизация адресов
функций, то есть при каждом новом запуске приложения адреса функций в памяти
будут меняться, плюс они могут содержать часто недопустимые байты, например
null-byte (такая техника используется к примеру в дистрибутиве Open Wall
GNU/Linux). С переполнениями в хипе (Heap Based Overflows) как правило борются,
создавая неисполняемый хип, который предотвращает выполнение любого кода в
данной области памяти (non-executable heap также содержится в некоторых
средствах защиты, по моим данным PaX Team впервые разработала такой модуль), а
также часто модифицируют процедуру менеджмента хипа, добавляя различные проверки
чанков (на валидность cookie, например). С атаками на ошибки форматной строки
(format string) дела обстоят немного иначе, как вариант можно перехватывать
вызовы уязвимых функций к библиотекам (например, syslog(), printf(), snprintf()
и пр, которые подвержены атакам форматной строки). По поводу шеллкодов, как вы
уже заметили, практически все эксплоиты используют шеллкод (ну, конечно,
существуют исключения, к примеру мы можем передать управление не нашему коду, а
какой-нибудь другой функции, уже заложенной в программе, но это большая
редкость). Шеллкод возможно перехватывать не только на уровне сети, но и на
уровне хоста. Для этих целей существуют HIPS (Host Intrusion Prevention System)
– специальное ПО, которое работает на уровне хоста и перехватывает функции,
анализирую их на наличие шеллкода. Проще говоря, это уже рассматриваемая нами
технология stack backtracing. Конечно, существуют некоторые способы обхода
данной технологии, но не надо забывать, что 99% эксплоитов используют
стандартные шеллкоды и методы эксплоитирования, которые никоим образом не
предназначены для тюнингованных специализированной защитой систем (не говоря уже
о том, что большинство людей, использующих эксплоит, часто понятия не имеют как
он работает, не говоря уже о его модификации для обхода защитных средств). Если
рассматривать другие атаки, такие как целочисленное переполнение (integer
overflow), adjancent memory overflow и frame pointer overwrite, то для
защищаемых средств они не играют большой роли, поскольку подобные атаки
позволяют лишь проэксплоитировать вышеуказанные уязвимости в коде.
По большому счету существует 2 метода нападения на систему – это либо
автоматизированные средства, либо “прямые” действия самого атакующего. Но для
нас это не играет большой роли, так как payload от этого не меняется. Но стоит
заметить, что даже mass/auto rooting редко происходит без получения какой-либо
информации о атакуемой системе, не говоря уже о “manual” взломе, то есть
пытаются определить хотя бы версию демона, так как нет никакого смысла атаковать
Apache 1.3.26 если стоит IIS/6.0. Анализ баннера в большинстве случаев – это
самый актуальный способ анализа (возможен также анализ по fingerprints
демонов/серверов для более точного определения версий и вообще принадлежности к
конкретной линейки продуктов, но я думаю, что такая ситуация для
автоматизированных средств в реальности маловероятна..). Так что тут встает еще
одна линия обороны – это скрытие информации от потенциального злоумышленника или
его автоматизированного средства. Security-сообщество пытается всех убедить что
“Security through obscurity” не приносит реальной безопасности. Отчасти это так,
но к примеру, если мне удастся убедить атакующего, что на моей машине стоит
скажем FreeBSD, а не Linux, то шеллкод, который будет использовать
злоумышленник, не будет работать на моей системе, даже если и получит
управление. На мой взгляд надо по возможности прятать все, что только можно.
Менять параметры, которые критичны для разлиных fingerprint-техник, менять
системные баннеры и другие информационные заголовки, по которым можно определить
версию демона/сервиса и тд. Одним словом вводить в заблуждение атакующего или
его автоматизированные средства. Более того, не забудьте грамотно настроить свой
файрволл, блокируйте неиспользуемые порты (это защитит вас от bind-шеллкодов),
контролируйте установку внешних соединений (это должно защитить вас от
reverse-connected шеллкодов, то есть когда ваша машина сама соединяется с
компьютером взломщика). Не забываейте также о Chroot и разделении привилегий –
это очень действенные меры по противодействию атакам (скажем “порутанный” apache
сбрасывает нам nobody shell, а если в /tmp запрещено выполнение программ,
ситуация незавидная для атакующего, даже без учета chroot). Если в chroot не
будет “/bin/sh” – то это просто отлично (98% unix-like шеллкодов выполняют
оболочку по этому адресу). Естественно, здесь я даже не устану упоминать о таких
вещах, как выбор стойких паролей, правильная установка прав доступа, постоянная
проверерка лог-файлов, контроль за действиями пользователей, безопасная
настройка демонов и тд, так как все это подробно описано во многих книгах и
учебниках по информационной безопасности.
Во второй части своего материала я расскажу более подробно о практических
методах защиты популярных операционных систем от 0-day, перехвате шеллкодов и
способах обхода сигнатур IDS.
Любой рынок постоянно развивается, и безопасность здесь не является
исключением. Но, к сожалению, в нашей стране (да и в остальном мире, но в
меньшей степени, я думаю..) забывают о реальном обеспечении защиты сводя все к
покупке продуктов вроде файрволла или очередной VPN-системы, а также созданию
политик безопасности и регламентов.. Только грамотная служба безопасности, либо действительно
квалифицированные администраторы, которые разбираются в тонкостях безопасности
вверенных им систем и сетевых устройств, могут обеспечить очень хорошую и реальную защиту предприятия от подобных атак! Но часто не того, не другого в
организациях попросту нет, что естественно печально, и если нет возможности
нанять квалифицированных специалистов по информационной безопасности, а
обеспечивать реальную, а не “бумажную” защиту все же надо, я надеюсь, что моя
статья помогла вам продвинуться в этом вопросе. И я также надеюсь, что этот
материал заставит вас задуматься над проблемами, которые принес нам рынок 0-day,
развивающийся молниеносными темпами и с каждым годом получая все больше и больше
финансовых вложений от “заинтересованных лиц”, которых, поверьте на слово,
совсем не интересует обеспечение безопасности. Вот и все, что я хотел сказать в
первой части материала. Ваши пожелания, дополнения, вопросы и замечания можно
направлять по адресу lakehin@miag.ru. Более подробную информацию вы всегда
сможете найти на сайте http://miag.ru.
Ссылки
В статье мы расскажем о наиболее интересных стартапах в области кибербезопасности, на которые следует обратить внимание.
Хотите узнать, что происходит нового в сфере кибербезопасности, – обращайте внимание на стартапы, относящиеся к данной области. Стартапы начинаются с инновационной идеи и не ограничиваются стандартными решениями и основным подходом. Зачастую стартапы справляются с проблемами, которые больше никто не может решить.
Обратной стороной стартапов, конечно же, нехватка ресурсов и зрелости. Выбор продукта или платформы стартапа – это риск, требующий особых отношений между заказчиком и поставщиком . Однако, в случае успеха компания может получить конкурентное преимущество или снизить нагрузку на ресурсы безопасности.
Ниже приведены наиболее интересные стартапы (компании, основанные или вышедшие из «скрытого режима» за последние два года).
Компания Abnormal Security, основанная в 2019 году, предлагает облачную платформу безопасности электронной почты, которая использует анализ поведенческих данных для выявления и предотвращения атак на электронную почту. Платформа на базе искусственного интеллекта анализирует поведение пользовательских данных, организационную структуру, отношения и бизнес-процессы, чтобы выявить аномальную активность, которая может указывать на кибератаку. Платформа защиты электронной почты Abnormal может предотвратить компрометацию корпоративной электронной почты, атаки на цепочку поставок , мошенничество со счетами, фишинг учетных данных и компрометацию учетной записи электронной почты. Компания также предоставляет инструменты для автоматизации реагирования на инциденты, а платформа дает облачный API для интеграции с корпоративными платформами, такими как Microsoft Office 365, G Suite и Slack.
Копания Apiiro вышла из «скрытого режима» в 2020 году. Ее платформа devsecops переводит жизненный цикл безопасной разработки «от ручного и периодического подхода «разработчики в последнюю очередь» к автоматическому подходу, основанному на оценке риска, «разработчики в первую очередь», написал в блоге соучредитель и генеральный директор Идан Плотник . Платформа Apiiro работает, соединяя все локальные и облачные системы управления версиями и билетами через API. Платформа также предоставляет настраиваемые предопределенные правила управления кодом. Со временем платформа создает инвентарь, «изучая» все продукты, проекты и репозитории. Эти данные позволяют лучше идентифицировать рискованные изменения кода.
Axis Security Application Access Cloud – облачное решение для доступа к приложениям , построенное на принципе нулевого доверия. Он не полагается на наличие агентов, установленных на пользовательских устройствах. Поэтому организации могут подключать пользователей – локальных и удаленных – на любом устройстве к частным приложениям, не затрагивая сеть или сами приложения. Axis вышла из «скрытого режима» в 2020 году.
BreachQuest, вышедшая из «скрытого режима» 25 августа 2021 года, предлагает платформу реагирования на инциденты под названием Priori. Платформа обеспечивает большую наглядность за счет постоянного отслеживания вредоносной активности. Компания утверждает, что Priori может предоставить мгновенную информацию об атаке и о том, какие конечные точки скомпрометированы после обнаружения угрозы.
Cloudrise предоставляет услуги управляемой защиты данных и автоматизации безопасности в формате SaaS. Несмотря на свое название, Cloudrise защищает как облачные, так и локальные данные. Компания утверждает, что может интегрировать защиту данных в проекты цифровой трансформации. Cloudrise автоматизирует рабочие процессы с помощью решений для защиты данных и конфиденциальности. Компания Cloudrise была запущена в октябре 2019 года.
Cylentium утверждает, что ее технология кибер-невидимости может «скрыть» корпоративную или домашнюю сеть и любое подключенное к ней устройство от обнаружения злоумышленниками. Компания называет эту концепцию «нулевой идентичностью». Компания продает свою продукцию предприятиям, потребителям и государственному сектору. Cylentium была запущена в 2020 году.
Компания Deduce , основанная в 2019 году, предлагает два продукта для так называемого «интеллектуального анализа личности». Служба оповещений клиентов отправляет клиентам уведомления о потенциальной компрометации учетной записи, а оценка риска идентификации использует агрегированные данные для оценки риска компрометации учетной записи. Компания использует когнитивные алгоритмы для анализа конфиденциальных данных с более чем 150 000 сайтов и приложений для выявления возможного мошенничества. Deduce заявляет, что использование ее продуктов снижает ущерб от захвата аккаунта более чем на 90%.
Автоматизированная платформа безопасности и соответствия Drata ориентирована на готовность к аудиту по таким стандартам, как SOC 2 или ISO 27001. Drata отслеживает и собирает данные о мерах безопасности, чтобы предоставить доказательства их наличия и работы. Платформа также помогает оптимизировать рабочие процессы. Drata была основана в 2020 году.
FYEO – это платформа для мониторинга угроз и управления доступом для потребителей, предприятий и малого и среднего бизнеса. Компания утверждает, что ее решения для управления учетными данными снимают бремя управления цифровой идентификацией. FYEO Domain Intelligence («FYEO DI») предоставляет услуги мониторинга домена, учетных данных и угроз. FYEO Identity будет предоставлять услуги управления паролями и идентификацией, начиная с четвертого квартала 2021 года. FYEO вышла из «скрытого режима» в 2021 году.
Kronos – платформа прогнозирующей аналитики уязвимостей (PVA) от компании Hive Pro , основанная на четырех основных принципах: предотвращение, обнаружение, реагирование и прогнозирование. Hive Pro автоматизирует и координирует устранение уязвимостей с помощью единого представления. Продукт компании Artemis представляет собой платформу и услугу для тестирования на проникновение на основе данных. Компания Hive Pro была основана в 2019 году.
Израильская компания Infinipoint была основана в 2019 году. Свой основной облачный продукт она называет «идентификация устройства как услуга» или DIaaS , который представляет собой решение для идентификации и определения положения устройства. Продукт интегрируется с аутентификацией SSO и действует как единая точка принуждения для всех корпоративных сервисов. DIaaS использует анализ рисков для обеспечения соблюдения политик, предоставляет статус безопасности устройства как утверждается, устраняет уязвимости «одним щелчком».
Компания Kameleon , занимающаяся производством полупроводников, не имеет собственных фабрик и занимает особое место среди поставщиков средств кибербезопасности. Компания разработала «Блок обработки проактивной безопасности» (ProSPU). Он предназначен для защиты систем при загрузке и для использования в центрах обработки данных, управляемых компьютерах, серверах и системах облачных вычислений. Компания Kameleon была основана в 2019 году.
Облачная платформа безопасности данных Open Raven предназначена для обеспечения большей прозрачности облачных ресурсов. Платформа отображает все облачные хранилища данных, включая теневые облачные учетные записи, и идентифицирует данные, которые они хранят. Затем Open Raven в режиме реального времени отслеживает утечки данных и нарушения политик и предупреждает команды о необходимости исправлений. Open Raven также может отслеживать файлы журналов на предмет конфиденциальной информации, которую следует удалить. Компания вышла из «скрытого режима» в 2020 году.
Компания Satori, основанная в 2019 году, называет свой сервис доступа к данным “DataSecOps”. Целью сервиса является отделение элементов управления безопасностью и конфиденциальностью от архитектуры. Сервис отслеживает, классифицирует и контролирует доступ к конфиденциальным данным. Имеется возможность настроить политики на основе таких критериев, как группы, пользователи, типы данных или схема, чтобы предотвратить несанкционированный доступ, замаскировать конфиденциальные данные или запустить рабочий процесс. Сервис предлагает предварительно настроенные политики для общих правил, таких как GDPR , CCPA и HIPAA .
Компания Scope Security недавно вышла из «скрытого режима», будучи основана в 2019 году. Ее продукт Scope OmniSight нацелен на отрасль здравоохранения и обнаруживает атаки на ИТ-инфраструктуру, клинические системы и системы электронных медицинских записей . Компонент анализа угроз может собирать индикаторы угроз из множества внутренних и сторонних источников, представляя данные через единый портал.
Основным продуктом Strata является платформа Maverics Identity Orchestration Platform . Это распределенная мультиоблачная платформа управления идентификацией. Заявленная цель Strata – обеспечить согласованность в распределенных облачных средах для идентификации пользователей для приложений, развернутых в нескольких облаках и локально. Функции включают в себя решение безопасного гибридного доступа для расширения доступа с нулевым доверием к локальным приложениям для облачных пользователей, уровень абстракции идентификации для лучшего управления идентификацией в мультиоблачной среде и каталог коннекторов для интеграции систем идентификации из популярных облачных систем и систем управления идентификацией. Strata была основана в 2019 году.
SynSaber , запущенная 22 июля 2021 года, предлагает решение для мониторинга промышленных активов и сети. Компания обещает обеспечить «постоянное понимание и осведомленность о состоянии, уязвимостях и угрозах во всех точках промышленной экосистемы, включая IIoT, облако и локальную среду». SynSaber была основана бывшими лидерами Dragos и Crowdstrike.
Traceable называет свой основной продукт на основе искусственного интеллекта чем-то средним между брандмауэром веб-приложений и самозащитой приложений во время выполнения. Компания утверждает, что предлагает точное обнаружение и блокирование угроз путем мониторинга активности приложений и непрерывного обучения, чтобы отличать обычную активность от вредоносной. Продукт интегрируется со шлюзами API. Traceable была основана в июле 2020 года.
Компания Wiz, основанная командой облачной безопасности Microsoft, предлагает решение для обеспечения безопасности в нескольких облаках, рассчитанное на масштабную работу. Компания утверждает, что ее продукт может анализировать все уровни облачного стека для выявления векторов атак с высоким риском и обеспечивать понимание, позволяющее лучше расставлять приоритеты. Wiz использует безагентный подход и может сканировать все виртуальные машины и контейнеры. Wiz вышла из «скрытого режима» в 2020 году.
Работает на CMS “1С-Битрикс: Управление сайтом”
fullz list icq cc dumps