Реализовать детектирование инжекта

Тема в разделе "WASM.COMMERCE", создана пользователем nagva27, 12 июн 2017.

Метки:
  1. nagva27

    nagva27 New Member

    Публикаций:
    0
    Регистрация:
    5 июн 2017
    Сообщения:
    13
    Добрый день!
    Есть программа, работающая под windows (r3), исходников её у меня нет. Мне нужно научиться узнавать, что в неё пытается совершить инжект другая программа, тоже работающая под r3. Она может делать это затем, чтобы узнать, какие winapi вызывает первая программа и с какими параметрами. Мне важно узнать, что такая попытка была.
    Собственно, нужен код (желательно делфи, но в принципе любой язык можно, если оно соберётся в .dll), который мог бы детектить любые такие попытки перехвата вызываемых api.
     
  2. Indy_

    Indy_ Well-Known Member

    Публикаций:
    4
    Регистрация:
    29 апр 2011
    Сообщения:
    4.775
    вnagva27,

    Можно реализовать механизмы, которые позволят обнаружить локальный инжект - изменения в памяти етц. Но оно обычно делается удалённо, из другого процесса. Поэтому никакой нотификации не будет, кроме штатных методов - запуска потоков. Память может быть изменена из другого процесса, тоесть через ядро. Может даже быть захвачен и изменён контекст потока. Что бы такое обнаружить можно использовать два способа - при изменении памяти по таймеру выполнять проверку целостности, а эта весьма сложная задача, так как захватить код можно без изменения статик памяти(кода), проверку переменных выполнить невозможно, либо визоры. Обнаружить изменение контекста - так же сложная задача. Можно создать поток - ловушку и проверять его. Но если инжектор реализован грамотно вы ничего не обнаружите. Так как методы детекта учитываются при имплементации инжекта, вы же не думаете что это пилят совсем глупые и не знают возможных методов детекта ?
    По факту вы хотите универсальное решение, которое невозможно, да есчо и в юм. Эта задача не решаема в принципе. Но можно создать костыль - фильтр, который будет мониторить потоки, в самом сложном случае это подтверждать локальную выборку данных(нужен визор) и по таймеру проверять целостность образов. Смысла в этом нет, это обходится после прочтения этой темы или отладки такой защиты за минуты.
     
    Последнее редактирование: 14 июн 2017
    nagva27 нравится это.
  3. vx1d

    vx1d Member

    Публикаций:
    0
    Регистрация:
    13 дек 2016
    Сообщения:
    118
    если программа которая делает инжект работает в r3, можно делаеть детект вызова функок: *OpenProcess, без этих фунок инжекта не может быть, если не учитовать dll hijacking.
     
  4. jupman

    jupman New Member

    Публикаций:
    0
    Регистрация:
    17 июн 2017
    Сообщения:
    2
    nagva27, а начиная с какой версии Windows требуется совместимость? Например на Windows 8.1 и выше можно запретить выделять исполняемую память (посредством SetProcessMitigationPolicy).
     
  5. Indy_

    Indy_ Well-Known Member

    Публикаций:
    4
    Регистрация:
    29 апр 2011
    Сообщения:
    4.775
    jupman,

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

    nagva27 New Member

    Публикаций:
    0
    Регистрация:
    5 июн 2017
    Сообщения:
    13
    vx1d, это очень интересно! Indy_, можете согласиться с тем, что любой инжект в r3, кроме dll hijacking, подразумевает вызов openProcess?
     
  7. Indy_

    Indy_ Well-Known Member

    Публикаций:
    4
    Регистрация:
    29 апр 2011
    Сообщения:
    4.775
    nagva27,

    Но открытие процесса не означает что будет выполнен инжект. В таком случае нужно как то обнаружить событие открытия в чужом процессе.
     
  8. nagva27

    nagva27 New Member

    Публикаций:
    0
    Регистрация:
    5 июн 2017
    Сообщения:
    13
    Indy_, имеете в виду, что мой процесс может "открыть" кто-то с помощью openProcess, чтобы просто посмотреть, как там дела? Ну наверное такое бывает, но очень редко и можно считать, что не бывает такого.
     
  9. Indy_

    Indy_ Well-Known Member

    Публикаций:
    4
    Регистрация:
    29 апр 2011
    Сообщения:
    4.775
    nagva27,

    Инжектиться во все процессы не получится, далее это вредоносная активность, а не защита. Ну и нет гарантий что получится отследить открытие процесса.
     
  10. Indy_

    Indy_ Well-Known Member

    Публикаций:
    4
    Регистрация:
    29 апр 2011
    Сообщения:
    4.775
    Видос для другой темы, но думаю для этой тоже годится, что бы показать бесперспективность попыток какого либо детекта. Никаких изменений памяти нет. Модуля даже не исполняются в данном случае :tease:

    https://yadi.sk/i/jaRS5EFT3KF38d
     
  11. Indy_

    Indy_ Well-Known Member

    Публикаций:
    4
    Регистрация:
    29 апр 2011
    Сообщения:
    4.775
    Примерная модель защиты.

    Приложение взято под визор. Всё АП не исполняемо, за исключением кодовой секции нтдлл(из за Ki-ядерных векторов).

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

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

    Через подобный механизм может быть реализована универсальная защита от OP(ROP/COP - это тоже инжект). Защита от ROP сводится к связыванию Call-ret(CET) и проверке на RET валидного адреса возврата(который формируется при каждом call'е под визором). Для COP валидация возможна только по целостности потока данных(DFG), это можно расширить и на ROP.

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

    В конечном итоге всё упирается в профайл визора. При пакетном исполнении(по блочно) профайл падает в три раза, но это при не оптимальной раскодировке инструкций.
     
  12. 0xC3

    0xC3 New Member

    Публикаций:
    0
    Регистрация:
    1 июл 2017
    Сообщения:
    20
    nagva27, Indy_, мож в коллбэках ловить новые потоки (имхо просто перехват апи без шекодов и потоков вряд ли производится)? я писал 100 лет назад еще на руткитсах выкладывал (свой -чужой поток как отследить). А сам факт инжекта - да, отдельный дебаг процесс для "чтобы узнать, какие winapi вызывает первая программа и с какими параметрами". Сорри с экранной клавы фигово писать, сделайте в итоге свой отлаживающий процесс, никто к отлаживаемому не сможет прицепиться.
     
  13. Indy_

    Indy_ Well-Known Member

    Публикаций:
    4
    Регистрация:
    29 апр 2011
    Сообщения:
    4.775
    0xC3,

    Модель описанная выше весьма продуманна. Остальные же способы - элементарно обходятся.
    Так если всё АП не исполняемо, то аллокация памяти удалённо и передача на неё управления любым способом - захват контекста рабочего потока например(setcontext) приведёт к передаче управления на NX память, либо на впрыснутый регион памяти, откуда ничего не возможно вызвать без запуска визора(так как АП не исполняемо). Что далее приведёт в первом случае к прямому срабатыванию ловушки, во втором случае код отработает некоторое время и обратиться к апи, что так же приведёт к срабатыванию ловушки. Более того, в старших версиях системы можно отключить аллокацию исполняемой памяти(ислючая образы).
     
  14. 0xC3

    0xC3 New Member

    Публикаций:
    0
    Регистрация:
    1 июл 2017
    Сообщения:
    20
    Indy_, Согласен про стэк, не пойму фразу: "Более того, в старших версиях системы можно отключить аллокацию исполняемой памяти(ислючая образы)."
     
  15. Indy_

    Indy_ Well-Known Member

    Публикаций:
    4
    Регистрация:
    29 апр 2011
    Сообщения:
    4.775
    0xC3,

    Про стек я вроде ничего не говорил :)

    ProcessDynamicCodePolicy
     
  16. neutronion_old_school

    neutronion_old_school Попугай Сильвера

    Публикаций:
    0
    Регистрация:
    23 июл 2017
    Сообщения:
    411
    чувак вроде код просто просит, а не разглагольствования. О ядре речи не было.
     
  17. Indy_

    Indy_ Well-Known Member

    Публикаций:
    4
    Регистрация:
    29 апр 2011
    Сообщения:
    4.775
    neutronion_old_school,

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