уязвимости в исходном коде

Поиск уязвимостей по исходному коду? Легко!

Многие программисты мучаются во время сна — им снится, что их проект был взломан, а исходники попали в открытый доступ.
Бывало такое? Нет? Как бы не так!

Сейчас я расскажу об очень простом методе поиска уязвимостей по исходному коду.
Да, именно по исходному коду, а не через GET/POST запросы с использованием различных программ.
Интересно — читайте дальше, а если не интересно — есть куда других интересных постов.

Введение

Для начала хотелось бы ввести вас в курс дела — поведать об задумке в целом и прочих мыслях.

Что же вы предлагаете?

Я предлагаю поиск узявимостей в PHP-сценариях с помощью специального PHP-сценария.

Почему именно такой подход?

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

Какие же гарантии по нахождению уязвимости?

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

Подготовимся к написанию?

Анализ самых распостранённых уязвимостей

Как же можно искать уязвимости?

Вспомните как вы в спешке, очень в спешке, писали код. Часто ли вы фильтровали переменные?
Уверен, что 60% вспомнят себя. Поэтому продумаем список возможных кодовых уязвимостей.

Список уязвимостей

Итог подготовки

Пишем скрипт!

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

# Запуск фунции для просмотра каталогов для нашей папки.
open_dir($dir);

Источник

Безопасность веб-приложений: от уязвимостей до мониторинга

Уязвимости веб-приложений возникают тогда, когда разработчики добавляют небезопасный код в веб-приложение. Это может происходить как на этапе разработки, так и на этапе доработки или исправления найденных ранее уязвимостей. Недостатки часто классифицируются по степени критичности и их распространенности. Объективной и наиболее популярной классификацией уязвимостей считается OWASP Top 10. Рейтинг составляется специалистами OWASP Project и актуализируется каждые 3-4 года. Текущий релиз выпущен в 2017 году, а следующий ожидается в 2020-2021.

Распространенные уязвимости

Для начала рассмотрим типовые уязвимости, которым подвержены многие веб-приложения.

Инъекции

Как и полагается, атаки класса «Инъекции» занимают лидирующую строчку рейтинга OWASP Top 10, встречаясь практически повсеместно и являясь крайне разнообразными в реализации. Уязвимости подобного класса начинаются SQL-инъекциями, в различных его вариациях, и заканчивая RCE — удаленным выполнением кода.

Межсайтовый скриптинг — уязвимость, встречающаяся на данный момент куда реже, чем раньше, если верить рейтингу OWASP Top 10, но несмотря на это не стала менее опасной для веб-приложений и пользователей. Особенно для пользователей, ведь атака XSS нацелена именно на них. В общем случае злоумышленник внедряет скрипт в веб-приложение, который срабатывает для каждого пользователя, посетившего вредоносную страницу.

LFI/RFI

Уязвимости данного класса позволяют злоумышленникам через браузер включать локальные и удаленные файлы на сервере в ответ от веб-приложения. Эта брешь присутствует там, где отсутствует корректная обработка входных данных, которой может манипулировать злоумышленник, инжектировать символы типа path traversal и включать другие файлы с веб-сервера.

Атаки через JSON и XML

Веб-приложения и API, обрабатывающие запросы в формате JSON или XML, также подвержены атакам, поскольку такие форматы имеют свои недостатки.

JSON (JavaScript Object Notation) — это облегченный формат обмена данными, используемый для связи между приложениями. Он похож на XML, но проще и лучше подходит для обработки с помощью JavaScript. Многие веб-приложения используют этот формат для обмена данными между собой и сериализации/десериализации данных. Некоторые веб-приложения также используют JSON для хранения важной информации, например, данных пользователя. Обычно используется в RESTful API и приложениях AJAX.

JSON чаще всего ассоциируется с API, тем не менее, часто используется даже в обычных и хорошо известных веб-приложениях. Например, редактирование материалов в WordPress производится именно через отправку запросов в формате JSON:

JSON Injection

Простая инъекция JSON на стороне сервера может быть выполнена в PHP следующим образом:

Простая инъекция JSON на стороне клиента может быть выполнена следующим образом:

JSON Hijacking

Захват JSON — атака, в некотором смысле похожая на подделку межсайтовых запросов (CSRF), при которой злоумышленник старается перехватить данные JSON, отправленные веб-приложению с веб-сервера:

XML External Entity

Атака внешней сущности XML (XXE) — это тип атаки, в котором используется широко доступная, но редко используемая функция синтаксических анализаторов XML. Используя XXE, злоумышленник может вызвать отказ в обслуживании (DoS), а также получить доступ к локальному и удаленному контенту и службам. XXE может использоваться для выполнения подделки запросов на стороне сервера (SSRF), заставляя веб-приложение выполнять запросы к другим приложениям. В некоторых случаях c помощью XXE может даже выполнить сканирование портов и удаленное выполнение кода.

XML (Extensible Markup Language) — очень популярный формат данных. Он используется во всем: от веб-сервисов (XML-RPC, SOAP, REST) до документов (XML, HTML, DOCX) и файлов изображений (данные SVG, EXIF). Для интерпретации данных XML приложению требуется анализатор XML, известный как XML-процессор. XML можно использовать не только для объявления элементов, атрибутов и текста. XML-документы могут быть определенного типа. Тип указывается в самом документе, объявляя определение типа. Анализатор XML проверяет, соответствует ли XML-документ указанному типу, прежде чем обрабатывать документ. Вы можете использовать два варианта определений типов: определение схемы XML (XSD) или определение типа документа (DTD). Уязвимости XXE встречаются в последнем варианте. Хотя DTD можно считать устаревшими, но он все еще широко используются.

Фактически, объекты XML могут поступать практически откуда угодно, включая внешние источники (отсюда и название XML External Entity). При этом, XXE может стать разновидностью атаки подделки запросов на стороне сервера (SSRF). Злоумышленник может создать запрос, используя URI (известный в XML как системный идентификатор). Если синтаксический анализатор XML настроен для обработки внешних сущностей, а по умолчанию многие популярные анализаторы XML на это настроены, веб-сервер вернет содержимое файла в системе, потенциально содержащего конфиденциальные данные.

Злоумышленник, разумеется, не ограничивается системными файлами. Можно легко заполучить и другие локальные файлы, включая исходный код, если известно расположение файлов на сервере или структура веб-приложения. Атаки на внешние объекты XML могут позволить злоумышленнику выполнять HTTP-запросы к файлам в локальной сети т.е. доступным только из-за брандмауэра.

Источник

Как использовать простую утилиту для поиска уязвимостей в программном коде

Graudit поддерживает множество языков программирования и позволяет интегрировать тестирование безопасности кодовой базы непосредственно в процесс разработки.

Источник: Unsplash (Markus Spiske)

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

Очевидно, что в современных реалиях разработки программного обеспечения важно обеспечить безопасность процессов. В своё время был даже введён специальный термин DevSecOps. Под этим термином понимают ряд процедур, направленных на выявление и устранение уязвимостей в приложении. Существуют специализированные open source решения для проверки уязвимостей в соответствии со стандартами OWASP, которые описывают различные типы и поведение уязвимостей в исходном коде.

Существуют разные подходы к решению проблем безопасности, например, статическое тестирование безопасности приложений (SAST), динамическое тестирование безопасности приложений (DAST), интерактивное тестирование безопасности приложений (IAST), анализ компонентов программного обеспечения (Software Composition Analysis) и так далее.

Статическое тестирование безопасности приложений выявляет ошибки в уже написанном коде. Этот подход не требует запуска приложения, поэтому он называется статическим анализом.

Я остановлюсь на статическом анализе кода и воспользуюсь простым open source инструментом, чтобы продемонстрировать всё на практике.

Почему я выбрал open source инструмент для статического анализа безопасности кода

На то есть ряд причин: во-первых, это бесплатно, так как вы используете инструмент, разработанный сообществом единомышленников, которые хотят помочь другим разработчикам. Если у вас небольшая команда или стартап, у вас есть отличная возможность сэкономить, используя программное обеспечение с открытым исходным кодом для проверки безопасности своей кодовой базы. Во-вторых, это избавляет вас от необходимости нанимать отдельную команду DevSecOps, что ещё больше снижает ваши расходы.

Хорошие open source инструменты всегда создают с учётом повышенных требований к гибкости. Поэтому их можно использовать практически в любом окружении, охватывая широкий круг задач. Разработчикам намного проще подружить такие инструменты с системой, которую они уже построили, работая над своими проектами.

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

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

Использование Graudit для анализа безопасности кода

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

Здесь мы будем использовать Graudit, простую утилиту для командной строки, которая позволит нам найти уязвимости в нашей кодовой базе. Он поддерживает разные языки, но всё-таки их набор ограничен. Graudit разработан на основе служебной утилиты grep, которая в своё время вышла под лицензией GNU.

Существуют похожие инструменты для статического анализа кода — Rough Auditing Tool for Security (RATS), Securitycompass Web Application Analysis Tool (SWAAT), flawfinder и так далее. Но Graudit очень гибок и имеет минимальные технические требования. Тем не менее, у вас могут появиться задачи, которые Graudit решить не в состоянии. Тогда можно поискать другие варианты вот в этом списке.

Мы можем интегрировать этот инструмент в конкретный проект, или сделать его доступным для выбранного пользователя, либо — использовать его одновременно во всех наших проектах. В этом тоже проявляется гибкость Graudit. Итак, давайте сначала клонируем репо:

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

Проверим, успешно ли прошла установка:

Если вы увидите что-то похожее, то, значит, всё хорошо.

Я буду тестировать один из уже существующих моих проектов. Перед запуском инструмента ему нужно передать базу данных, соответствующую языку, на котором написан мой проект. Базы данных находятся в папке

Итак, я протестировал два js-файла из моего проекта, и Graudit вывел в консоль информацию об уязвимостях в моём коде:

Можете попробовать таким же образом протестировать ваши проекты. Список баз данных для разных языков программирования можно посмотреть здесь.

Преимущества и недостатки Graudit

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

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

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

Начало.

В этой статье я рассмотрел только один из многих способов поиска уязвимостей — статическое тестирование безопасности приложений. Провести статический анализ кода легко, но это только начало. Чтобы больше узнать о безопасности вашей кодовой базы, нужно интегрировать в жизненный цикл разработки ПО другие виды тестирования.

На правах рекламы

Надёжный VPS и правильный выбор тарифного плана позволят меньше отвлекаться от разработки на неприятные проблемы — всё будет работать без сбоев и с очень высоким uptime!

Источник

Контроль уязвимостей в программных приложениях

Дефекты программного кода

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

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

Самый распространенный дефект – это ошибки программистов при разработке кода. Зачастую причиной их появления является дефицит времени или потеря внимания во время работы. Например, программист разрабатывает код, который в определенных условиях должен выполнять одни действия, а во всех остальных случаях – другие. Программист уделяет большое внимание разработке кода, который будет выполняться в 90% случаях исполнения ПО. Когда же дело доходит до обработки альтернативы, он устает, его внимание рассеивается, и какие-то важные аспекты, такие как оператор, определяющий выполнение данного фрагмента кода, только если условие выполнения основного фрагмента не выполнилось, теряются.

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

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

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

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

Самые неприятные с точки зрения возможности обнаружения дефекты – недекларированные возможности ПО (НДВ). Недекларированные возможности – это правильный код с точки зрения и функциональности, и информационной безопасности, поэтому его трудно обнаружить автоматическими методами. Однако этот код реализует функциональность, которая не была задумана заказчиком – ее для своих целей привнес разработчик. Обычно НДВ разделяют на закладки и секретный вход (back door).

Закладка – это функциональность, которая выполняется при наступлении определенных условий и выполняет действия, задуманные разработчиком. Часто закладки используются для того чтобы неявно манипулировать программным обеспечением. Один из наиболее известных случаев наличия закладки – история разработчика City Bank. Программист не знал, что делать с разницей, возникающей при округлении результатов арифметических операций при начислении процентов на вклады клиентов, и не придумал ничего лучше, чем накапливать ее на своем персональном счете.

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

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

Откуда берутся дефекты в программном коде?

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

Зачастую требования к программному обеспечению меняются быстрее, чем ИТ-команда успевает их реализовывать. Дается одно техническое задание, оно прорабатывается архитектором, конструкторами и передается в работу. Но в процессе заказчик разработки понимает: новые условия рынка требуют, чтобы разрабатываемое ПО выполняло другой функционал. Несмотря на возражения ИТ-команды, вносятся изменения в проектную документацию, а зачастую и непосредственно в код, ломая при этом проработанную архитектуру.

Другой причиной появления ошибок и уязвимостей является сложность технологий, использующихся в современной ИТ-индустрии.

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

Появление в коде недекларированных возможностей носит исключительно личностный характер и с трудом контролируется посредством внедрения современных технологий разработки ПО. Хотя практика перекрестного контроля разработки (прежде чем код попадает в основную ветку разработки, его обязательно проверяет другой программист) и другие организационные меры имеют определенный успех. Обнаружить недекларированные возможности в коде, который разрабатывался на заказ и куда НДВ были внедрены специально, можно только посредством его анализа.

Можно ли контролировать наличие дефектов в программном коде?

На сегодняшний день на рынке представлено несколько инструментальных систем анализа кода, как статического (по исходному коду методом «белого ящика»), так и динамического (без исходного кода методом «черного ящика»). Помимо этого, ведущие инструментальные системы анализа кода от таких производителей, как HP и IBM, предлагают комбинированный статический и динамический анализ, который позволяет отображать результаты динамического анализа на исходный код. Можно сказать, что в настоящее время наиболее эффективным инструментальным средством анализа кода, которое предлагает статический, динамический, а также гибридный анализ в сочетании с удобным интерфейсом и хорошей библиотекой правил поиска уязвимостей, является инструментальное средство HP Fortify.

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

Контролировать уязвимости в программном обеспечении, которое поставляется на заказ, сложно, так как информация о наличии дефектов проходит долгий путь проверок, а затем следует не менее длительный процесс их устранения. Однако это не значит, что такое ПО не нужно проверять и стоит эксплуатировать как «кота в мешке». Рекомендуется выполнять контроль уязвимостей посредством правильной настройки защиты периметра эксплуатации.

Источник

Роковые ошибки. Как искать логические уязвимости в веб-приложениях

Содержание статьи

Эта статья — кон­спект вебина­ра по веб‑уяз­вимос­тям, который я про­водил для читате­лей «Хакера». В кон­це будет при­веде­на его запись, где ты смо­жешь уви­деть то, что не попало в тек­сто­вую вер­сию. Если тебе инте­рес­ны такие темы и ты бы хотел разоб­рать­ся в них глуб­же, за­писы­вай­ся на мой курс по безопас­ности веб‑при­ложе­ний!

Сра­зу пре­дуп­режу, что боль­шинс­тво задач, которые мы сегод­ня раз­берем, будут на язы­ке PHP. Оно нес­прос­та — подав­ляющее боль­шинс­тво сай­тов и сер­висов в интерне­те написа­ны имен­но на нем. Так что, нес­мотря на под­порчен­ную репута­цию это­го язы­ка, тебе при­дет­ся раз­бирать­ся в нем, что­бы хакерс­тво­вать серь­езно. Сей­час же, в рам­ках это­го занятия, зна­ние PHP не явля­ется необ­ходимостью, но, конеч­но, будет очень серь­езным под­спорь­ем.

Впро­чем, боль­шинс­тво уяз­вимос­тей не при­вяза­ны к кон­крет­ному язы­ку или сте­ку тех­нологий, так что, узнав их на при­мере PHP, ты лег­ко смо­жешь экс­плу­ати­ровать подоб­ные баги и в ASP.NET, и в каком‑нибудь Node.JS.

А еще пре­дуп­режу, что задач­ки, которые мы сегод­ня раз­берем, не сов­сем началь­ного уров­ня и сов­сем уж «вален­кам» тут делать нечего — сна­чала сто­ит почитать мат­часть и хоть нем­ного пред­став­лять, с чем хочешь иметь дело. Если же ты можешь отли­чить HTTP от XML и у тебя не воз­ника­ет воп­росов вида «а что за дол­лары в коде?», то доб­ро пожало­вать!

warning

Ни автор кур­са, ни редак­ция «Хакера» не несут ответс­твен­ности за твои дей­ствия. При­мене­ние матери­алов этой статьи про­тив любой сис­темы без раз­решения ее вла­дель­ца прес­леду­ется по закону.

Се­год­ня мы раз­берем нес­коль­ко задач, которые я решал сам в рам­ках тре­ниров­ки. Воз­можно, они покажут­ся тебе слож­ными, но не пугай­ся — всег­да есть воз­можность отто­чить свои навыки на сай­тах пра­витель­ств спе­циали­зиро­ван­ных сай­тах для хакеров. Я сей­час говорю о HackTheBox и Root-me, которы­ми поль­зуюсь сам и вся­чес­ки советую дру­гим. Две из сегод­няшних задач взя­ты имен­но отту­да.

Задача 1

Сна­чала я при­веду код, с которым мы сей­час будем работать.

По сути, тут все­го три стро­ки кода. Казалось бы, где тут может зак­расть­ся уяз­вимость?

Что­бы это понять, давай раз­берем алго­ритм, который здесь реали­зован. Вооб­ще, при ауди­те кода сто­ит уметь читать его пос­троч­но. Тог­да про­ще понять, что имен­но может пой­ти не так.

В кон­це очи­щен­ное имя фай­ла под­став­ляет­ся в путь и заг­ружа­ется файл с этим име­нем. Ничего пло­хого.

Итак, что может пой­ти не по пла­ну?

Как ты уже, конеч­но, догадал­ся — проб­лема в фун­кции очис­тки вво­да (которая preg_replace ). Давай обра­тим­ся к пер­вой попав­шей­ся шпар­галке по регуляр­ным выраже­ниям.

Шпар­галка

Тут пря­мо написан ответ, как обой­ти защиту (под­сказ­ка: ищи спра­ва).

Ви­дишь точ­ку? А шапоч­ку ( ^ )? Та стро­ка чита­ется как «если в начале стро­ки находит­ся любое количес­тво любых сим­волов, кро­ме перено­са стро­ки, и это закан­чива­ется сле­шем, уда­лить соот­ветс­тву­ющую часть стро­ки».

Клю­чевое тут «кро­ме перено­са стро­ки». Если в начале стро­ки будет перенос стро­ки — регуляр­ка не отра­бота­ет и вве­ден­ная стро­ка попадет в include( ) без филь­тра­ции.

Ре­зуль­тат

Задача 2

Это за­дач­ка с root-me, где ты, воз­можно, уже видел ее. Но мы все рав­но рас­смот­рим ее под­робнее — она отно­сит­ся к реалис­тичным, и шан­сы встре­тить что‑то подоб­ное в жиз­ни немалень­кие.

В задании нам дает­ся прос­той фай­лооб­менник и про­сят получить дос­туп к панели адми­на.

Ин­терфейс фай­лооб­менни­ка

Ин­терфейс край­не прост: есть кноп­ка заг­рузки фай­ла на сер­вер и прос­мотр заг­ружен­ных фай­лов по пря­мым ссыл­кам. Забегая впе­ред, ска­жу, что гру­зить скрип­ты на PHP, bash и про­чие — бес­полез­но, про­вер­ки реали­зова­ны вер­но и ошиб­ка в дру­гом мес­те.

Об­рати вни­мание на ниж­нюю часть стра­ницы, а точ­нее — на фра­зу «frequent backups: this opensource script is launched every 5 minutes for saving your files». И при­веде­на ссыл­ка на скрипт, вызыва­емый каж­дые пять минут в сис­теме.

Да­вай гля­нем на него прис­таль­нее:

Ка­залось бы — что тут такого? На парамет­ры ты вли­ять не можешь, а ман­тру при­зыва tar вооб­ще зна­ешь как свои пять паль­цев. А проб­лема в самой ман­тре: тут она написа­на не пол­ностью. Точ­нее, не в том виде, как ее уви­дит сам tar.

Что дела­ет звез­дочка? Вмес­то нее bash под­ста­вит име­на всех фай­лов в текущей пап­ке. Вро­де ничего кри­миналь­ного.

А давай обра­тим­ся к ма­нуалу на Tar, который нам любез­но пре­дос­тавлен вмес­те с усло­вием задачи.

Ин­терес­ности в Tar

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

Прос­то заголо­вок и коман­да копиро­вания админ­ской панели в текущую пап­ку. Естес­твен­но, тут мог быть реверс‑шелл или еще что‑то, но для решения кон­крет­но этой задачи такая «тяжелая артилле­рия» не нуж­на.

Те­перь дожида­емся выпол­нения нашего шел­ла — и уви­дим в окне фай­лооб­менни­ка файл админ‑панели в виде прос­того тек­ста. Оста­лось толь­ко открыть его и най­ти там пароль!

Па­роль в чис­том виде

Задача 3

Тут у нас пла­гин для WordPress, который поз­воля­ет запись аудио и видео.

Я не буду про­сить тебя най­ти уяз­вимость, а сра­зу покажу ее.

Уяз­вимое мес­то

Как вид­но из строк 247–251 на скрин­шоте, не пре­дус­мотре­но никаких про­верок на тип или содер­жимое фай­ла — это прос­то клас­сичес­кая заг­рузка!

Есть, прав­да, огра­ниче­ние: файл гру­зит­ся в стан­дар­тную дирек­торию WordPress ( / wordpress/ wp-content/ uploads/< YEAR>/ < MONTH>). Это зна­чит, что лис­тинг содер­жимого нам по умол­чанию недос­тупен. А в стро­ке 247 генери­рует­ся слу­чай­ный иден­тифика­тор, который под­став­ляет­ся в начало име­ни фай­ла, то есть обра­тить­ся к / wordpress/ wp-content/ uploads/ 2021/ 01/ shell. php уже не вый­дет. Непоря­док!

По­луча­ет уни­каль­ный иден­тифика­тор с пре­фик­сом, осно­ван­ный на текущем вре­мени в мик­росекун­дах.

Вни­мание. Эта фун­кция не гаран­тиру­ет получе­ния уни­каль­ного зна­чения. Боль­шинс­тво опе­раци­онных сис­тем син­хро­низи­рует вре­мя с NTP либо его ана­лога­ми, так что сис­темное вре­мя пос­тоян­но меня­ется. Сле­дова­тель­но, воз­можна ситу­ация, ког­да эта фун­кция вер­нет неуни­каль­ный иден­тифика­тор для про­цес­са/потока.

Так как PHP — про­ект откры­тый, мы можем под­смот­реть исходни­ки фун­кций стан­дар­тной биб­лиоте­ки. Откры­ваем исходник uniqid( ) на GitHub, перехо­дим к стро­ке 76 и наб­люда­ем сле­дующее:

Что тут про­исхо­дит? А то, что воз­вра­щаемое зна­чение зависит исклю­читель­но от текуще­го вре­мени, которое в рам­ках одной пла­неты впол­не пред­ска­зуемо.

Хоть выход­ная пос­ледова­тель­ность и выг­лядит слу­чай­ной, она таковой не явля­ется. Что­бы не быть голос­ловным, вот при­мер име­ни фай­ла, сге­нери­рован­ного таким алго­рит­мом:

По­лучен­ное зна­чение лег­ко мож­но кон­верти­ровать обратно в дату и вре­мя его генера­ции:

Ко­неч­но, бру­тить все 13 сим­волов — вши заедят, но у нас есть спо­соб получ­ше: мы можем проб­рутить вари­анты на осно­ве вре­мени заг­рузки плюс‑минус пол­секун­ды, что­бы нивели­ровать раз­бежки часов на кли­енте и сер­вере. А мож­но прос­то поверить, что часы у обо­их хос­тов точ­ные, а зна­чит, мож­но про­верить не мил­лион вари­антов (1 секун­ду), а толь­ко вари­анты, воз­можные меж­ду вре­менем отправ­ки зап­роса и вре­менем получе­ния отве­та. На шус­тром канале это будет поряд­ка 300–700 мс, что не так и мно­го.

Ко­неч­но, не все реаль­ные кей­сы тре­буют глу­боких поз­наний в PHP или дру­гом сер­верном язы­ке. Мно­гие ошиб­ки мож­но най­ти, даже не откры­вая код — с помощью авто­мати­чес­ких ска­неров. Под­робнее о них — в на­шей статье об авто­мати­чес­ком взло­ме. Они здо­рово помога­ют, так что не грех иметь пароч­ку под рукой для экс­пресс‑ана­лиза!

Я наб­росал прос­той скрипт на Python для демонс­тра­ции такой воз­можнос­ти. Его код пред­став­лен ниже:

Нам нуж­но запус­тить его нес­коль­ко раз, что­бы подоб­рать минималь­ное вре­мя меж­ду отправ­кой зап­роса и получе­нием отве­та — это поз­волит умень­шить вре­мя перебо­ра.

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

Как бы еще опти­мизи­ровать перебор?

Ну, во‑пер­вых, питон сам по себе очень мед­ленный и, конеч­но, не смог бы выпол­нить соеди­нение, переда­чу заголов­ков, отправ­ку фай­ла и про­чие мел­кие нак­ладные рас­ходы в тот же момент. А интер­пре­татор PHP на сто­роне сер­вера едва ли момен­таль­но про­верит пра­ва, запус­тит скрипт, отра­бота­ет слу­жеб­ные фун­кции и дой­дет до собс­твен­но уяз­вимого мес­та. Тут мож­но накинуть эдак тысяч сто мик­росекунд без малей­ших потерь.

Во‑вто­рых, выпол­нение uniqid( ) оче­вид­но про­исхо­дит не в самом кон­це фун­кции. Еще нуж­но вре­мя на обра­бот­ку заг­ружен­ного фай­ла, запись отве­та (заголов­ков), отправ­ку это­го все­го по сети и на обра­бот­ку отве­та интер­пре­тато­ром Python. Тут тоже мож­но поряд­ка 100 000 мик­росекунд вычесть.

Вот так на ров­ном мес­те мы сок­ратили перебор на 200 000 зап­росов. Мно­го это или мало? В моем слу­чае это сок­ратило количес­тво зап­росов еще при­мер­но на треть.

Ос­талось поряд­ка 500 000 вари­антов, которые мож­но переб­рать в пре­делах часа или даже мень­ше — у меня это заняло минут 15.

Те­перь давай напишем еще один скрипт, который и будет искать наш шелл с исполь­зовани­ем это­го алго­рит­ма:

Вот и всё: запус­каешь, через некото­рое вре­мя получа­ешь путь, и хост зах­вачен!

На­вер­няка у тебя воз­ник воп­рос, нель­зя ли как‑то еще усо­вер­шенс­тво­вать этот перебор, потому что 500 тысяч вари­антов — это все рав­но как‑то мно­гова­то? Мож­но, но такого зна­чимо­го уско­рения, как рань­ше, уже не будет. Суть в том, что мож­но идти не от начала про­межут­ка вре­мени к кон­цу, а от середи­ны к кра­ям. По опы­ту, это работа­ет нес­коль­ко быс­трее.

Другой способ

Задача 4

Пос­ледняя на сегод­ня задач­ка — тоже с root-me и тоже из катего­рии реалис­тичных, но замет­но пос­ложнее. Сер­вис Web TV — новей­шая фран­цуз­ская раз­работ­ка в сфе­ре интернет‑телеви­дения. Но нас инте­ресу­ет не новая дешевая тра­гедия, а админка.

Глав­ная стра­ница Web TV. Прос­тите за мой фран­цуз­ский

Толь­ко — вот незада­ча — Gobuster никаких приз­наков админки не обна­ружил. При­дет­ся изу­чать, что нам дос­тупно. А дос­тупен логин (там фор­ма авто­риза­ции) и ссыл­ка на нерабо­тающий эфир.

Поп­робу­ем залоги­нить­ся и перех­ватить зап­рос на авто­риза­цию с помощью Burp.

Бук­ва З в сло­ве «реаль­ность» озна­чает «защищен­ность»

Зап­рос отправ­ляем в Repeater (пов­торитель). Пусть пока там полежит.

Взгля­нем еще разок на фор­му логина. Какие мыс­ли тебя посеща­ют, ког­да ты видишь фор­му для авто­риза­ции? Конеч­но, SQL-инъ­екция! А давай ткнем туда кавыч­ку. Написа­ли. Отправ­ляем. Хм, ничего не поменя­лось. А как вооб­ще узнать, что что‑то поменя­лось? Смот­ри на заголо­вок Content-Length в отве­те: в нашем слу­чае там при­ходит ров­но 2079 байт, если инъ­екции не было, и, оче­вид­но, при­дет силь­но дру­гой резуль­тат в про­тив­ном слу­чае. Я поп­робовал еще нем­ного, и инъ­екция так прос­то не выяви­лась, так что давай поищем в дру­гом мес­те, а потом вер­немся к это­му зап­росу.

Я поп­робовал перей­ти на стра­ницу / page_index и получил ошиб­ку как на скри­не ниже.

Ошиб­ка интер­пре­тато­ра

/?action=../../index.php

Вид­но не все, но если открыть ответ в Burp или даже прос­то прос­мотреть код стра­ницы бра­узе­ром — откры­вает­ся пол­ный исходник. Вот тебе и directory traversal налицо.

Ре­зуль­тат обхо­да катало­га

Пом­нишь, мы не мог­ли най­ти путь к админке? А на скрин­шоте он есть: имен­но на него будет редирект, ког­да скрипт про­верит логин и пароль.

Да­вай, не отхо­дя от кас­сы, сра­зу и его про­чита­ем — вдруг там что‑нибудь инте­рес­ное есть.

Источник