Техника сетевых атак
Шрифт:
·
Этот протокол полезен тем, что позволяет установить: в какой процедуре произошло переполнение буфера. В листинге знаком звездочки отмечена инструкция, следующая за командой, вызвавшей исключение:
· 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).
Рисунок 084
Приведенный пример относится к самым простым. Но существуют более коварные ошибки, проявляющиеся лишь при стечении определенных обстоятельств и обнаружить их можно только случайно или тщательным изучением исходных кодов (а в отсутствии исходных кодов - дизассемблированием или отладкой).
В первую очередь необходимо отобразить внимание на буфера фиксированного размера, расположенные в стеке. Блоки памяти, выделяемые вызовом alloc, находятся в куче (heap) и их переполнение (даже если и имеет место) не приводит к модификации адреса возврата, сохраненного в стеке.
Но четкую инструкцию по поиску ошибок дать невозможно. Существует множество разнообразных техник и подходов к решению этой проблемы, но никакой алгоритм не в в состоянии обнаруживать все уязвимости, поскольку всегда возможно возникновение принципиально новой идеи, наподобие приема, основанного на вводе спецификаторов в строке, передаваемой функции printf [335]. Автоматизированные средства поиска научаться обнаружить такие ошибки не раньше, чем обзаведутся искусственным интеллектом.
В сложных программах огрехи были, если и будут всегда. Тщательное тестирование миллионов строк кода современных приложений экономически не выгодно и не практикуется ни одной компанией. С другой стороны, анализ чужого кода (а особенно в отсутствии исходных текстов) выполнить в одиночку затруднительно. Большинство ошибок обнаруживаются случайно, а не в результате целенаправленного поиска. Но существует огромное количество злоумышленников, располагающих неограниченным (ну, практически неограниченным) временем для экспериментов, поэтому, новые ошибки обнаруживаются чуть ли не ежедневно (и часто по несколько в день).
Как устроен генератор паролей?
O В этой главе:
O Алгоритмы перебора пароля
O Достоинства и недостатки словарного перебора
O Оценка стойкости пароля
O Расчет количества времени гарантирующего нахождение пароля
O Поиск пароля в худшем и среднем случаях
Один из способов получения несанкционированного доступа к защищенному ресурсу заключается в подборе пароля. Такую операцию крайне редко удается выполнить вручную, и обычно ее перекладывают на плечи программ-переборщиков паролей.
Существует несколько алгоритмов генерации паролей. Например, можно составить список наиболее распространенных паролей, а затем извлекать слова из списка одно за другим. Это, так называемый, словарный перебор. Его достоинство заключается в том, что удачно подобранный словарь способен позволить найти пароль за сравнительно небольшое количество попыток. Но что означает «удачно подобранный»? Пользователи склонны выбирать короткие запоминающиеся пароли, часто представляющие собой собственные имена, торговые марки, географические названия и слова ненормативной лексики (это уж как у кого голова работает). Все вместе взятые они с легкостью вмещаются в пять - десять тысяч вариантов, и могут быть перебраны за очень короткое время. (Современные бытовые компьютеры способны перебирать сотни тысяч паролей в секунду, поэтому словарь из десяти тысяч слов может быть испытан менее чем за секунду).