• XSS.stack #1 – первый литературный журнал от юзеров форума

Sandboxes

Отслеживать
Lille more bit optimise #3.
Выполнен в виде шеллкода, полностью базонезависим.
Теперь сканирует call и jmp, можете добавить недостающие команды.

Размер: 71 байт(5 минут назад было 74 байта:)).
INPUT: esp - address, where to return.
OUTPUT: eax: 1 - jmp found / 0 - nothng found.
ebx: addr of bad func.

Код: 
64A1300000008B400C8B400C8B40185003403C8B80800000005B03C38B401003C383380074118B18803BE87416803BE9741183C004EBEA83780600740583C004EBDFC333C040C3

Тесты:
kerberos 1.13 API spy
 

Вложения

  • ex.JPG
    ex.JPG
    75.7 КБ · Просмотры: 146
Lille more bit optimise #4.
Выполнен в виде шеллкода, полностью базонезависим.
Детектит любой ring3 хукер.
Теперь сканирует call, jmp, push/ret.

Размер: 77 байт.
INPUT: esp - address, where to return.
OUTPUT: eax: 1 - jmp found / 0 - nothng found.
ebx: addr of bad func.

Код: 
64A1300000008B400C8B400C8B40185003403C8B80800000005B03C38B401003C383380074178B18803BE8741C803BE97417807B05C3741183C004EBE483780600740583C004EBD9C333C040C3
 
С таких вот шеллкодесов конечно все и начинается, потом появляется сорс писаный на коленке, потом консолька, потом прога с GUI с последующим ее ежедневным юзаньем, при этом экономя массу времени.. но...
Я бы все-таки пошел как всегда против течения, детек сделал бы на основе сравнения кода находящегося в памяти и оригинала файла на диске(подсчет MD5 обоих участков кода, и если MD5 различаются то мы похучены), это позволит задетектить почти все "физические" хуки
Вот, к примеру, в шеллкоде вот сразу слету увидел недостаток
Проверка идет на E8, E9 и C3, а EB(к примеру) не проверяется
А у аверов есть правила (не формальные правдо-о), и условная договоренность с ахтунгами из Microsoft
Если, к примеру, взять user32.dll, kernel32.dll итд. из XP и посмотреть...
посмотреть на начало кода любой API, к примеру GetModuleHandleA:
Код: 
7C80B524                  90              NOP
7C80B525                  90              NOP
7C80B526                  90              NOP
7C80B527                  90              NOP
7C80B528                  90              NOP
7C80B529 GetModuleHandleA 8BFF            MOV EDI,EDI
7C80B52B                  55              PUSH EBP
7C80B52C                  8BEC            MOV EBP,ESP
7C80B52E                  837D 08 00      CMP DWORD PTR SS:[EBP+8],0
7C80B532                  74 18           JE SHORT 7C80B54C
7C80B534                  FF75 08         PUSH DWORD PTR SS:[EBP+8]
7C80B537                  E8 682D0000     CALL 7C80E2A4
7C80B53C                  85C0            TEST EAX,EAX
7C80B53E                  74 08           JE SHORT 7C80B548
7C80B540                  FF70 04         PUSH DWORD PTR DS:[EAX+4]
7C80B543                  E8 F4300000     CALL GetModuleHandleW
7C80B548                  5D              POP EBP
7C80B549                  C2 0400         RETN 4
7C80B54C                  64:A1 18000000  MOV EAX,DWORD PTR FS:[18]
7C80B552                  8B40 30         MOV EAX,DWORD PTR DS:[EAX+30]
7C80B555                  8B40 08         MOV EAX,DWORD PTR DS:[EAX+8]
7C80B558                  EB EE           JMP SHORT 7C80B548
Вот эта MOV EDI,EDI нужна, чтобы при хуке установить ближний джамп (EB F9 JMP SHORT 7C80B524), не заботясь при этом о сохранении похученых байт
А вместо нопов пишут уже дальний джамп (E9) на код обработчика хука
Разница между вариантами очевидна, в первом - шеллкод мал и требует постоянного внимания на апгрейды, и не известно до каких размеров он вырастет, когда в нем будет большее количество детектов разных хуков
Во втором – размер "немного" больше, но детект будет максимальный, апгрейды минимальны и не зависит от того AV это или же Sandboxes итд.
ЗЫ: ИМХО
 
Я бы все-таки пошел как всегда против течения, детек сделал бы на основе сравнения кода находящегося в памяти и оригинала файла на диске(подсчет MD5 обоих участков кода, и если MD5 различаются то мы похучены), это позволит задетектить почти все "физические" хуки
Подумывал тоже над этим, именно из-за:

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

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

Пароль:
xss.pro/9213129udsadu1203812385kjsf
 

Вложения

  • sample.rar
    756 байт · Просмотры: 131
Способы обхода патчей:
1)Чтение оригинальной библиотеки на диске и замена нужных байт.
2)Копирование оригинальной библиотеки в другое место(скажем временную директорию) и замена нужных байт оттуда.
Есть ещё идеи ?
 
Chococream
детектит любые ring3 хуки
Если под "хуки" понимать фильтра шадова(что ставится через SetWindowHookEx() etc), то детектить там даже нечего.

Если имеются ввиду вообще способы контроля за кодом, то любые способы в принципе не реально детектить. Максимум это две секции через cmps сравнить(если патч) да и всё.

3.
Перемапить или релоцировать образ.
 
Indy
В посте #27 у меня как раз мапится образ с диска и сравниваются значения.
С описанием "детектит любые ring3 хуки" я переборщил.

релоцировать образ
Можно подробнее ?
Я так понял, это оно:
http://indy-vx.narod.ru/DLab/Relocate.zip
 
Chococream
Можно и так. Главное не испортить переменные. Чтобы их сохранить, можно:
1. Не трогая секции данных, восстановить секции кода. Это не эффективный путь.

2. Загрузить копию модуля как в семпле. Подобным образом есчо русток поступал(дроппер какието сетевые либы релоцировал). У этого семпла есть недостаток - запись об модуле, это можно легко обойти. Выгрузка модуля, который в базе загрузчика помечен флагом LDRP_COR_OWNS_UNMAP приводит к сохранению проекции, а только она нужна. Тоесть:
Код: 
	DllHandle = LdrLoadImage()
	Header = FindEntryForAddress(DllHandle)
	LDR_DATA_TABLE_ENTRY.Flags[Header] or LDRP_COR_OWNS_UNMAP
	LdrUnloadDll(DllHandle)
Но следует заметить что образ связан с файлом и это может служить детектом.

ImCopy.png

- Обратите внимание на адреса переменных.

Код: 
Local TableEntry:PLDR_DATA_TABLE_ENTRY
	...
	invoke LdrFindEntryForAddress, DllHandle2, addr TableEntry
	mov ecx,TableEntry
	%NTERR
	bts LDR_DATA_TABLE_ENTRY.Flags[ecx],23; LDRP_COR_OWNS_UNMAP
	btr LDR_DATA_TABLE_ENTRY.Flags[ecx],18; LDRP_DONT_CALL_FOR_THREADS
	invoke LdrUnloadDll, DllHandle2

3. Сохранить копию образа в буфере(секции данных), выгрузить модуль, загрузить его по прежней базе и восстановить секции данных из буфера. Весьма похоже на п.1. Немного изменённый вариант - создать не файловую секцию(Section Object), спроецировать её, копировать туда секции данных, выгрузить модуль, загрузить модуль, созранить в секции(Obj) секции кода из проекции модуля, выгрузить модуль, спроецировать секцию(Obj) частями по исходной базе, причём секции данных мапяться на R/W, секции кода - R/E. Тогда в проекции код будет невозможно изменить в юзермоде.
 
Предлагаю обсудить методы изоляции заражённого ПО.
Из основных:
1)Эмуляция ПК(прим. VmWare, VirtualBox, qemu, bochs, etc...).
2)HIPS(у аверов) a.k.a sandbox. Представляет из себя обычный ring0 драйвер(встречаются камикадзе-варианты с длл), фильтрующий запросы, предназначенные системным модулям: драйверу диска, файловой системы, модема и т.п.
3)Эмуль. Представляет из себя эмулятор(полноценный) intel инструкций. Системные api либо имитируются, либо возвращается базово STATUS_SUCCESS ;)

Самый эффективный метод - первый, на котором и базируются все основные malware analysis сервисы.
Встречал ли кто-нибудь подобные песочницы с исходным кодом ?
 
_http://www.cuckoobox.org/
Правда на питоне.
Смотрел этот проект, надстройка над VBox.
Одно НО: в процесс инжектится дллка, а хотелось бы что-то на нулевом кольце.

Нашёл ещё несколько ресурсов:
ZeroWine:
http://sourceforge.net/projects/zerowine/

ZeroWine Tryouts:
http://zerowine-tryout.sourceforge.net/

Truman Sandbox:
http://www.secureworks.com/research/tools/truman/
 
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх