Изменяем запретное

Крис Касперски

Хакер, номер #090, стр. 090-122-1

Как хакеры CRC16/32 подделывают

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

Алгоритм CRC16/32 изначально предназначался для контроля целости данных от непреднамеренных искажений. Он широко используется в проводных и беспроводных сетях, магнитных и оптических носителях, а также микросхемах постоянной или перешиваемой памяти. "Надежность" CRC32 оценивается как 2^32 == 4.294.967.296, то есть вероятность, что контрольная сумма искаженного файла "волшебным" образом совпадет с оригиналом, оценивается (в среднем) как один против четырех миллиардов раз. Отсюда следует, что, передав восемь миллиардов пакетов через сильно зашумленный канал, мы рискуем получить пару "битых" пакетов, чьи искажения останутся необнаруженными. Но ведь в действительности все совсем не так! Природа большинства физических помех и дефектов носит групповой характер, с которым CRC32 легко справляется и в реальной жизни. Никакие искажения от CRC32 не ускользают!

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

Скажу откровенно: наличие механизмов самоконтроля серьезно раздражает хакеров и препятствует пошаговой трассировке step-by-step, при которой отладчик внедряет CCh после каждой команды. Однако хакеров лучше не злить. Разъяренный хакер взрывоопасен! Размахивая soft-ice, словно топором, и прикрываясь дизассемблером, как щитом, он находит и поле контрольной суммы, и тот код, который ее контролирует, после чего обоим настает конец.

Кстати говоря, "правильная" контрольная сумма должна быть равна нулю. Это закон! Именно так работает механизм самоконтроля BIOS'ов. В этом случае контрольная сумма нигде не хранится, но к содержимому прошивки добавляются четыре байта (в CRC16 – два байта), рассчитанных так, чтобы контрольная сумма всего контролируемого блока обращалась в ноль. В этом случае ломать защиту становится намного труднее (ведь поля контрольной суммы нет!), но все-таки возможно. Достаточно установить аппаратную точку останова на модифицированную команду (в soft-ice это делается так: "bpm adders R"), и отладчик приведет нас к коду, который вычисляет контрольную сумму и на каком-то этапе выносит заключение CRC OK или CRC не OK.

Обычно хакеры "отламывают" непосредственно сам проверяющий механизм, чтобы программа работала независимо от того, какой у нее CRC, однако этот способ срабатывает не везде и не всегда. Вспомним спор, возникший в конференции SU.VIRUS по поводу инспектора AdInfo: может ли вирус заразить файл так, чтобы его контрольная сумма осталась неизменной? Может! Даже если весь файл проверяется целиком от ушей до хвоста! Чуть позже мы покажем, как это сделать, а сейчас рассмотрим другой случай: клиент серверной системы, в которой ключевой файл (условно называемый "сертификатом") находится у клиента, а его контрольная сумма хранится и проверяется на сервере. В состав сертификата может входить все, что угодно: название организации, IP-адрес клиента, его "рейтинг", уровень "полномочий" в системе и т. д. и т. п. Весьма распространенный подход, не правда ли? Чтобы повысить уровень своих полномочий, клиент должен модифицировать файл сертификата, что с неизбежностью влечет за собой изменение контрольной суммы, скрупулезно проверяемой сервером, взломать который значительно сложнее, чем подправить пару байт в hiew'е!