HTTP запросы и модули Apache: Творческие векторы атаки

Question

Немного неортодоксальные вопрос здесь:

В настоящее время я пытаюсь разбить Apache с несколькими пользовательскими модулями.

Что порождает тестирование, так это то, что Apache внутренне пересылает запросы, которые он считает слишком большими (например, мусор 1 МБ), к соответствующим образом подключенным к ним модулям, заставляя их работать с данными мусора - и отсутствие обработки в пользовательских модулях вызвало Apache в полном объеме, чтобы подняться в огне. Ой, ой, ой.

Эта конкретная проблема, к счастью, исправлена, но возникает вопрос, могут ли быть другие подобные уязвимости.

Сейчас у меня есть инструмент, который позволяет мне отправлять необработанный HTTP-запрос на сервер (точнее, необработанные данные через установленное TCP-соединение, которое может быть интерпретировано как HTTP-запрос, если оно следует за формой одного , например «GET ...»), и я пытаюсь придумать другие идеи. (Атаки TCP уровня, как Slowloris и Nkiller2 являются не моего внимания на данный момент.)

Кто-нибудь есть несколько хороших идей, как запутать пользовательские модули сервера к точке сервера самосожжения?

• Разбитый UTF-8? (Хотя я сомневаюсь, что Apache заботится о кодировании - я предполагаю, что он просто жонглирует сырыми байтами.)
• Материал, который только слишком длинный, за которым следует 0-байтовый, за которым следует барахло?
• и так далее

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

(Если StackOverflow не является правильным местом для этого вопроса, я извиняюсь. Не уверен, что где-то поставить его.)

Answer 1

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

• Bad кодировок - например overong utf-8, как вы упомянули, есть сценарии, в которых модули зависят от этого, например, определенных параметров.
• манипуляция параметрами - опять же, в зависимости от того, что делают модули, некоторые параметры могут обманываться с ними, изменяя значения, удаляя ожидаемые параметры или добавляя неожиданные.
• вопреки вашего другое предложение, я хотел бы посмотреть на данных, которые едва достаточно короткий, то есть один или два байта короче, чем максимум, но в разных комбинациях - различные параметры, заголовки, тело запрос и т.д.
• Посмотрите на HTTP Request Smuggling (также и here) - неправильные заголовки запросов или недопустимые комбинации, такие как несколько Content-Length или недопустимые терминаторы, может заставляют модуль неправильно интерпретировать команду из Apache.
• Также рассмотрите gzip, закодированное кодирование и т. Д. Вероятно, что пользовательский модуль реализует проверку длины и декодирование, не в порядке.
• Что относительно частичного запроса? например, запросы, которые вызывают ответ 100-Continue или запросы диапазона?
• Инструмент fuzzing, Peach, рекомендованный компанией @TheRook, также является хорошим направлением, но не ожидайте, что в этом случае ROI впервые получит его.
• Если у вас есть доступ к исходному коду, обзор целенаправленного кода безопасности - отличная идея. Или даже автоматическое сканирование кода с помощью инструмента, такого как Coverity (как упоминалось в @ TheRook), или лучшего ...
• Даже если у вас нет доступа к исходному коду, рассмотрите тест проникновения в систему безопасности, либо опытным консультант/пентестер или, по крайней мере, с помощью автоматизированного инструмента (их много) - например appscan, webinspect, netsparker, acunetix и т. д.

Answer 2

Apache является одним из самых укрепленных проектов программного обеспечения на лице планеты. Обнаружение уязвимости в HTTPD Apache было бы небольшим подвигом, и я рекомендую отрезать зубы на более легкой добыче. Для сравнения чаще встречаются уязвимости в других HTTPD, например, в Nginx, которые я видел сегодня (без шуток). Были и другие уязвимости, раскрывающие исходный код, которые очень похожи, я бы посмотрел на this и вот another. lhttpd был оставлен на sf.net почти на протяжении десятилетия, и существуют известные переполнения буфера, которые влияют на него, что делает его интересным приложением для тестирования.

При атаке проекта вы должны посмотреть, какие уязвимости были обнаружены в прошлом. Вероятно, программисты будут повторять те же ошибки снова и снова, и часто появляются шаблоны. Следуя этим шаблонам, вы можете найти больше недостатков. Вы должны попытаться найти базы данных уязвимостей, такие как Nist's search for CVEs. Одна вещь, которую вы увидите, это то, что модули apache чаще всего подвергаются риску.

Проект, подобный Apache, был сильно раздет. Существуют пушистые рамки, такие как Peach. Персик помогает с путаницей по-разному, одним из способов, которым он может помочь вам, - дать вам некоторые неприятные тестовые данные для работы.Fuzzing - не очень хороший подход для зрелых проектов, если вы идете по этому маршруту, я бы нацелил apache modules с минимальными загрузками. (Предупреждающие проекты с действительно низкие загружаемые файлы могут быть сломаны или сложны в установке.)

Когда компания беспокоится о secuirty, они часто платят большие деньги за автоматизированный инструмент для анализа источников, такой как Coverity. Департамент внутренней безопасности предоставил Coverity массу денег для тестирования проектов с открытым исходным кодом и Apache is one of them. Я могу сказать вам из первых рук, что я нашел a buffer overflow с путаницей, что Coverity не подобрал. Скрытность и другие инструменты для анализа исходного кода, такие как open source Rats, будут создавать множество ложных срабатываний и ложных негативов, но они помогают сузить проблемы, которые влияют на базу кода.

(Когда я впервые запустил RATS на ядре Linux, я чуть не упал со своего стула, потому что на моем экране перечислены тысячи вызовов на strcpy() и strcat(), но когда я выкопал в код все вызовы, со статическим текстом, который является безопасным.)

Уязвимость resarch - разработка эксплойта - a lot of fun. Я рекомендую использовать приложения PHP/MySQL и изучать The Whitebox. Этот проект важен, потому что он показывает, что есть некоторые уязвимости в реальном мире, которые не могут быть найдены, если вы не прочитаете код по строке вручную. Он также имеет приложения реального мира (блог и магазин), которые очень уязвимы для атаки. Фактически оба этих приложения, которые отказались из-за проблем с безопасностью. Веб-приложение fuzzer, например, Wapiti или acuentix, изнасиловает эти приложения и подобные им. В блоге есть трюк. Новая установка не очень уязвима. Вы должны использовать приложение немного, попробуйте войти в систему как администратор, создайте запись в блоге, а затем отсканируйте его. При тестировании приложения веб-приложения для SQL-инъекции убедитесь, что отчет об ошибках включен. В php вы можете установить display_errors=On в свой php.ini.

Удачи!