Фундаментальные основы хакерства. Проверка аутентичности и базовый взлом защиты

Содержание статьи

• Проверка аутентичности
• Шаг первый. Разминочный
• Листинг 1. Пример простейшей системы аутентификации
• Листинг 2
• Шаг второй. Знакомство с дизассемблером
• Шаг третий. Хирургический
• Продолжение следует?

Пятнадцать лет назад эпический труд Криса Касперски «Фундаментальные основы хакерства» был настольной книгой каждого начинающего исследователя в области компьютерной безопасности. Однако время идет, и знания, опубликованные Крисом, теряют актуальность. Редакторы «Хакера» попытались обновить этот объемный труд и перенести его из времен Windows 2000 и Visual Studio 6.0 во времена Windows 10 и Visual Studio 2017.

Проверка аутентичности

Проверка аутентичности (от греч. authentikos — подлинный) — «сердце» подавляющего большинства защитных механизмов. Должны же мы удостовериться, то ли лицо, за которое оно себя выдает, работает с программой и разрешено ли этому лицу работать с программой вообще!
В качестве «лица» может выступать не только пользователь, но и его компьютер или носитель информации, хранящий лицензионную копию программы. Таким образом, все защитные механизмы можно разделить на две основные категории:

• защиты, основанные на знании (пароля, серийного номера);
• защиты, основанные на обладании (ключевым диском, документацией).

Если защита базируется на одном лишь предположении, что ее код не будет изучен и/или изменен, — это плохая защита. Отсутствие исходных текстов отнюдь не служит непреодолимым препятствием для изучения и модификации приложения. Современные технологии обратного проектирования позволяют автоматически распознавать библиотечные функции, локальные переменные, стековые аргументы, типы данных, ветвления, циклы и прочее. А в недалеком будущем дизассемблеры, вероятно, вообще научатся генерировать листинги, близкие по внешнему виду к языкам высокого уровня.

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

Шаг первый. Разминочный

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

Достоинство такой защиты — крайне простая программная реализация. Ее ядро состоит фактически из одной строки, которую на языке С можно записать так:

if (strcmp(введенный пароль, эталонный пароль)) {/* Пароль неверен */} else {/* Пароль ОK*/} 

Давайте дополним этот код процедурами запроса пароля и вывода результатов сравнения, а затем испытаем полученную программу на прочность, то есть на стойкость к взлому:

Листинг 1. Пример простейшей системы аутентификации

#include "stdafx.h" // Простейшая система аутентификации —  // посимвольное сравнение пароля  #include <stdio.h> #include <string.h> #define PASSWORD_SIZE 100 #define PASSWORD "myGOODpasswordn" // Этот перенос нужен затем, чтобы  // не выкусывать перенос из строки, // введенной пользователем int main() {     // Счетчик неудачных попыток аутентификации      int count=0;     // Буфер для пароля, введенного пользователем      char buff[PASSWORD_SIZE];     // Главный цикл аутентификации      for(;;)     {         // Запрашиваем и считываем пользовательский          // пароль         printf("Enter password:");          fgets(&buff[0],PASSWORD_SIZE,stdin);         // Сравниваем оригинальный и введенный пароль          if (strcmp(&buff[0],PASSWORD))         // Если пароли не совпадают — «ругаемся»         printf("Wrong passwordn");         // Иначе (если пароли идентичны)         // выходим из цикла аутентификации         else break;         // Увеличиваем счетчик неудачных попыток          // аутентификации и, если все попытки          // исчерпаны, завершаем программу          if (++count>3) return -1;     } // Раз мы здесь, то пользователь ввел правильный  // пароль  printf("Password OKn"); } 

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

Не так уж редко пароли представляют собой осмысленные слова наподобие Ferrari, QWERTY, имена любимых хомячков или названия географических пунктов. Угадывание пароля сродни гаданию на кофейной гуще — никаких гарантий на успех нет, остается рассчитывать на одно лишь везение. А удача, как известно, птица гордая — палец в рот ей не клади. Нет ли более надежного способа взлома?

Давайте подумаем. Раз эталонный пароль хранится в теле программы, то, если он не зашифрован каким-нибудь хитрым образом, его можно обнаружить тривиальным просмотром двоичного кода программы. Перебирая все встретившиеся в ней текстовые строки, начиная с тех, что более всего смахивают на пароль, мы очень быстро подберем нужный ключ и откроем им программу! Причем область просмотра можно существенно сузить — в подавляющем большинстве случаев компиляторы размещают все инициализированные переменные в сегменте данных (в PE-файлах он размещается в секции .data или .rdata). Исключение составляют, пожалуй, ранние багдадские (Borland’овые) компиляторы с их маниакальной любовью всовывать текстовые строки в сегмент кода — непосредственно по месту их вызова. Это упрощает сам компилятор, но порождает множество проблем. Современные операционные системы, в отличие от старушки MS-DOS, запрещают модификацию кодового сегмента, и все размещенные в нем переменные доступны лишь для чтения. К тому же на процессорах с раздельной системой кеширования они «засоряют» кодовый кеш, попадая туда при упреждающем чтении, но при первом же обращении к ним вновь загружаются из медленной оперативной памяти (кеша второго уровня) в кеш данных. В результате — тормоза и падение производительности.

Что ж, пусть это будет секция данных! Остается только найти удобный инструмент для просмотра двоичного файла. Можно, конечно, нажать клавишу F3 в своей любимой оболочке (FAR, например) и, придавив кирпичом клавишу Page Down, любоваться бегущими цифирьками до тех пор, пока не надоест.

Можно воспользоваться любым hex-редактором (QView, Hiew…) — кому какой по вкусу, — но в статье, по соображениям наглядности, приведен результат работы утилиты DUMPBIN из штатной поставки Microsoft Visual Studio. DUMPBIN запускается из Developer Command Prompt.

Натравим утилиту на исполняемый файл нашей программы, в котором лежит пароль, и попросим ее распечатать содержащую инициализированные только для чтения данные секцию — rdata (ключ /SECTION:.rdata) в «сыром» виде (ключ /RAWDATA:BYTES), указав значок ˋ>ˋ для перенаправления вывода в файл (ответ программы занимает много места, и на экране помещается один лишь «хвост»).

Продолжение доступно только подписчикам

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

Подпишись на «Хакер» по выгодной цене!

Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов. Подробнее о подписке

Уже подписан?

Источник