ТЕХНИКА СЕТЕВЫХ АТАК - Крис Касперский

Этот протокол полезен тем, что позволяет установить: в какой процедуре произошло переполнение буфера. В листинге знаком звездочки отмечена инструкция, следующая за командой, вызвавшей исключение:

· 015f:0040125d e80afeffff call 0040106c = BUFF.DEMO.EXE:.text+0x6c

· BUFF.DEMO.EXE:.text+0x262:

· *015f:00401262 83c40c add esp,+0c

С помощью IDA легко установить, что процедура, располагающая по адресу 0x40106C, представляет собой main():

·.text:0040106C main proc near; CODE XREF: start+AFp

·.text:0040106C push ebp

·.text:0040106D mov ebp, esp

Но переполнение буфера произошло в процедуре auth, ссылок на адрес которой (0х401000) в протоколе, выданном Доктором Ватсоном вообще нет! Это происходит потому что, адрес возврата из процедуры auth был затерт введенной строкой и Доктор Ватсон не смог определить откуда произошел вызов. Исключение вызвала не сама функция main, а одна из вызываемых ею процедур. Установить же истинного «виновника» исключения теперь практически невозможно.

Единственной зацепкой, за которую можно ухватиться оказываются параметры переданные функции (если они не были затерты [334]). По роду и значению параметров можно хотя бы приблизительно определить какая функция была вызвана. По крайней мере, это позволит сузить круг поиска.

Но далеко не во всех случаях ошибки переполнения удается обнаружить перебором строк разной длины. Наглядной демонстрацией этого утверждения служит следующая программа (на диске, прилагаемом к книге, она находится в файле “/SRC/buff.src.c”):

· #include «stdio.h»· #include «string.h»· #include «windows.h»·· int file(char *buff)· {· char *p;· int a=0;· char proto[10];· p=strchr( amp;buff[0],':');· if (p)· {· for (;a!=(p- amp;buff[0]);a++)· proto[a]=buff[a];·· proto[a]=0;·· if (strcmp( amp;proto[0],"file"))· return 0;· else· WinExec(p+3,SW_SHOW);··}· else· WinExec( amp;buff[0],SW_SHOW);· return 1;··}··· main(int argc,char **argv)· {· if (argc»1) file( amp;argv[1][0]);·}

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

Если в имени файла присутствует символ “:”, то программа полагает, что имя записано в формате “протокол://путь к файлу/имя файла”, и пытается выяснить какой именно протокол был указан. При этом она копирует название протокола в буфер фиксированного размера, полагая, что при нормальном ходе вещей, его хватит для вмещения имени любого протокола. Но если ввести строку наподобие “ZZZZZZZZZZZZZZZZZZZZZZ:”, то произойдет переполнение буфера со всеми вытекающими отсюда последствиями (см. рисунок 084).

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

В первую очередь необходимо отобразить внимание на буфера фиксированного размера, расположенные в стеке. Блоки памяти, выделяемые вызовом alloc, находятся в куче (heap) и их переполнение (даже если и имеет место) не приводит к модификации адреса возврата, сохраненного в стеке.

Но четкую инструкцию по поиску ошибок дать невозможно. Существует множество разнообразных техник и подходов к решению этой проблемы, но никакой алгоритм не в в состоянии обнаруживать все уязвимости, поскольку всегда возможно возникновение принципиально новой идеи, наподобие приема, основанного на вводе спецификаторов в строке, передаваемой функции printf [335]. Автоматизированные средства поиска научаться обнаружить такие ошибки не раньше, чем обзаведутся искусственным интеллектом.

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

O В этой главе:

O Алгоритмы перебора пароля

O Достоинства и недостатки словарного перебора

O Оценка стойкости пароля

O Расчет количества времени гарантирующего нахождение пароля

O Поиск пароля в худшем и среднем случаях

Один из способов получения несанкционированного доступа к защищенному ресурсу заключается в подборе пароля. Такую операцию крайне редко удается выполнить вручную, и обычно ее перекладывают на плечи программ-переборщиков паролей.

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

Словарный перебор срабатывает часто, но не всегда. Привилегированные пользователи (такие, как, например, администраторы систем) склонны выбирать бессмысленные пароли наподобие “acsW%9*m$”, надежно защищая себя от словарной атаки. В таком случае приходится прибегать к последовательному перебору всех возможных паролей. Такой подход гарантирует, что искомый пароль рано или поздно будет найден, но требует значительного времени на поиск, часто сравнимый со временем жизни планет и звезд.

Поэтому, последовательный перебор целесообразен только в поиске коротких паролей или паролей, состоящих из небольшого количества символов. Некоторые системы аутентификации ограничивают максимальную длину пароля, позволяя гарантированной найти его путем перебора за приемлемое время. Случается, что такое ограничение возникает неявно в результате программной ошибки реализации (например, фактическая длина пароля LAN Manager составляет семь символов, поскольку две половинки четырнадцатисимвольной строки обрабатываются независимо друг от друга [336]).

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

Но что означает «короткий» и «длинный» пароль? Три символа, семь символов, десять символов, семьдесят шесть символов… Пароль какой длины может считаться надежно защищенным от перебора? Строго говоря, ни какой, поскольку любой пароль конечной длины можно подобрать за конечное время. Но в зависимости от скорости перебора и длины пароля время поиска может оказаться очень большим и даже превысить период существования самой Вселенной! Это ограничивает разумную длину пароля сверху. А время актуальности защищаемого ресурса огранивает ее снизу.

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

Точно так, злоумышленник, не знающий, сколько времени займет подбор пароля той или иной длины, не может назвать его ни длинным, ни коротким. Конечный ответ зависит не длины пароля самой по себе, а от времени, необходимого на его перебор. Ограничение на длину паролей в восемь символов какой-то десяток лет назад не казалась разработчикам UNIX чем-то ненормальным. По вычислительным мощностям того времени такая длина была более чем достаточна и требовала для полного перебора порядка двухсот миллионов лет. Технический прогресс уменьшил этот срок в сотни тысяч раз, и с каждым годом все продолжат уменьшать.