Social Icons

воскресенье, 20 сентября 2009 г.

"Белая шляпа": анализ брешей безопасности в Delphi/C++ Builder 2010

Оригинал: White Hat: Delphi/C++ Builder 2010 security flaws analysis. Автор: DelphiHaters.

Ваш покорный слуга надевает свою белую шляпу и изучает Delphi/C++ Builder 2010 на предмет дыр безопасности.

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

Мне интересно, кто именно скомпилировал печально известную библиотеку-"святилище" (sanctuary.dll - прим. пер.), которая была предназначена для защиты Delphi/C++ Builder, но, кажется, на самом деле все наоборот...
Кто бы это ни был, он должен был убрать то огромное количество отладочной информации и утверждений, которое содержится внутри библиотеки. В последней версии DLL столько отладочных символов, что вы бы смогли отследить в ней каждую функцию и процедуру. (См. ниже).


[некоторые части были скрыты (redacted).]

Так как же "они" прорвались?
Делая анализ безопасности,

вариант 1:
1. При загрузке BDS.exe не "проверяет" содержимое диска, только оперативную память.
2. Таким образом, она проверяет целостность "святилища" в памяти и никак иначе.
3. Патч бы отключал необходимые проверки (переключал Ложь на Истину) и затем
4. вызывал другой патч, который возващал бы данные обратно в память в то место, где они были изменены.
5. Т.к. следующей операцией являлась бы попытка проверить содержимое памяти
6. она бы проходила на ура и BDS успешно запускалась.

варинт 2:
1. При старте, конкретная DLL, отвечающая за обеспечение "определенных функций", имеет недокументированные функции для отключения проверки зашиты от копирования;
2. Тогда бы она переписывала конкретные значения памяти или "патчила" sanctuary.dll
3. Т.к. bds.exe не проверяла "святилище" [но она делает это сейчас :)],
4. BDS бы успешно запустилась.

Ваш покорный слуга рекомендует:
1. Добавить в BDS.EXE проверку содеримого диска по MD5 для предотвращения несанкционированного использования.
2. Добавить в DCC32.EXE самопроверку перед запуск компиляции из командной строки.
3. Добавить взаимную проверку библиотек DLL.
4. Несколько раз вызывать проверку целостности "святилища" в ран-тайме.
5. Избавиться от всей отладочной информации, в которой они действительно не нуждаются.
6. Обращаться к головному серверу используя UDP или DNS протоколы.
7. Будучи запущенной на виртуальной машине, определять это, и, возможно, не разрешать установку или запуск на ВМ без специальных лицензий для ВМ.
8. Собирать больше информации при обращении к головному серверу, например, имя пользователя Windows, сетевое имя домена, временную зону, языковые настройки Windows, имя в MSN, номер ICQ, имя в Skype, логин Yahoo Messenger, почтовые учетные записи Outlook, Thunderbird, и так далее...

Тс-ссс! Никому не рассказывайте :)

Комментариев нет:

Отправить комментарий

Поделитесь с друзьями!

 

Подписчики

Статистика