На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

Исследование по методу "серого ящика"

В исследованиях по методу "серого ящика"" объединены методы "белого ящика" и способы тестирования с помощью входных данных по методу "черного ящика". Удачным примером простого анализа по методу "серого ящика" является запуск программы внутри отладчика и подача на вход этой программы различных данных. При этом идет выполнение программы, а отладчик используется для выявления ошибок и некорректных состояний. Коммерческая программа Purify от компании Rational обеспечивает подробный анализ во время выполнения программы и в ос­новном направлена на исследование работы с памятью. Это особенно важно для программ на С и C++ (известных своими проблемами при выделении памяти). Valgrind — это бесплатный отладчик, который обеспечивает анализ программы во время ее выполнения в среде Linux.
В целом, все методы тестирования позволяют раскрыть риски для программного обеспечения и потенциальные возможности для проведения атак. Анализ по методу
"белого ящика" позволяет выявить большее число ошибок, но в этом случае трудно измерить действительный риск проведения атаки. Анализ по методу "черного ящи­ка" выявляет реальные проблемы, которыми гарантированно можно воспользовать­ся при атаках. Метод "серого ящика" позволяет объединить оба метода с максималь­ной выгодой. Тесты по методу "черного ящика" позволяют проверить программы по сети. Для проведения анализа по методу "белого ящика" требуется доступ к исход­ному или машинному коду для статического исследования. Как правило, сначала используется метод "белого ящика" для выявления потенциально проблематичных мест, а затем применяются методы "черного ящика" для создания работающих про­грамм атаки, направленных на эти проблематичные области.
Основная проблема для всех типов тестирования (и по методу "черного ящика", и по методу "белого ящика") состоит в том, что в них не исследуются все аспекты программ, т.е. большинство организаций, занимающихся оценкой качества про­граммного обеспечения, заботятся только о проверке функциональных возможно­стей и затрачивают совсем немного времени на проверку безопасности. В большин­стве коммерческих фирм, занимающихся разработкой программного обеспечения, нарушается процесс проверки качества приложений из-за ограничений относитель­но времени, экономии средств, но главным образом из-за уверенности в том, что при создании программы проверка качества не является основным аспектом работы.
Но в последнее время, с ростом значимости программного обеспечения, все больше внимания уделяется процессу проверки качества программного обеспече­ния. Разрабатывается единый, унифицированный подход к тестированию и анализу программ, включающий в себя проверки безопасности, надежности и производи­тельности программных продуктов. В процессе управления качеством программ ис­пользуется анализ как по методу "белого ящика", так и по методу "черного ящика" в целях выявления и управления рисками на максимально ранней стадии жизненного цикла программного обеспечения.
Поиск уязвимых мест в Microsoft SQL Server 7 с помощью метода "серого ящика"
При анализе программ по методу "серого ящика", как правило, используются не­сколько средств. В нашем примере будут использованы средства отладки для про­верки программы во время ее выполнения совместно с генератором входных данных по методу "черного ящика". Напомним, что использование средств выявления оши­бок и отладчиков, проверяющих работу программы во время ее выполнения, — чрез­вычайно мощный метод выявления проблем в программном обеспечении. При совместном применении со средствами внесения ошибок отладчики позволяют выявить просчеты в программном обеспечении. Во многих случаях дизассембли-рование программы позволяет точно определить истинную причину дефекта про­граммы, как будет показано в нашем примере.
Одним из мощнейших средств для динамического исследования программного обеспечения можно назвать Purify от компании Rational. В нашем примере с помо­щью программы Hailstrorm мы реализуем процесс внесения ошибок по отношению к программе SQL Server 7 от компании Microsoft и одновременно будем отслеживать состояние атакуемой программы с помощью Purify. Совместное использование про­грамм Purify и Hailstrorm позволяет выявить проблему затирания данных в памяти, которая проявляется в SQL Server после внесения некорректных данных в пакет протокола. Сбой в работе памяти происходит в результате возникновения исключе­ния и его неправильной обработки.
Прежде всего, нужно определить точку для ввода входных данных для SQL-сер­вера. SQL-сервер ожидает запросов на соединение на ТСР-порт 1443. Для этого пор­та нет спецификации используемого протокола. Вместо восстановления исходного кода и определения правил работы этого протокола, проведем простой тест, вводя случайные входные данные, включающие строки цифр. Эти данные передаются на TCP-порт. В результате формируются многочисленные "нормальные" пакеты, дос­тавляемые на искомый порт и таким образом покрывается широкий диапазон вход­ных значений. Набор входных пакетов доставляется за несколько минут с интенсив­ностью около 20 пакетов в секунду.
Входные данные обрабатываются различными фрагментами кода в программе SQL-сервера. В этих фрагментах кода, по существу, выполняется чтение заголовков протокола. По истечении небольшого периода это приводит к возникновению ошиб­ки, и Purify уведомляет об искажении информации в памяти.
Продемонстрируем факт возникновения ошибки в SQL-сервере с помощью снимков экрана на рисунке 3.2, где совмещены дамп памяти, сделанный программой Purify, и отчет о тестировании Hailstorm. Обнаруженное Purify искажение информа­ции в памяти происходит до отказа в работе SQL-сервера. Хотя атака и приводит к отказу в работе SQL-сервера, но без Purify трудно определить место искажения информации. Благодаря отчету Purify можно найти точное место в программном ко­де, в котором происходит ошибка.
В данном случае обнаружение ошибки происходит до проведения реальной ата­ки. Если попробовать обнаружить эту программу атаки только с помощью средств "черного ящика", то придется потратить несколько дней, прежде чем удастся вы­явить эту ошибку. Искажение информации в памяти может вызывать сбой програм­мы в совершенно другом участке кода, что усложняет определение того, какие вход­ные данные являются причиной ошибки. С помощью средств статического анализа можно определить факт искажения информации в памяти, но эти средства не позво­ляют узнать, может ли эта ошибка быть использована на практике злоумышленни­ком. Объединение двух методов, продемонстрированное в нашем примере, позволя­ет сэкономить массу времени и взять лучшее от обоих методов.

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика