Нулевой байт в php

Содержание

Ядовитый нулевой байт
Строгость
Эксплойт Вероятность
эксплуатация
Perl PHP Null Byte Injection
Adobe PDF ActiveX Null Byte Attack
Java Null Byte Injection
.NET Null Byte Injection
Решения
PHP
Perl
Adobe
.NET
Нулевой байт (Null Byte Injection, Null Byte Poisoning attack) в Java, Perl, PHP
Comments
Рубрики
Теги
Архив

Ядовитый нулевой байт

Отравленного NUL Байты первоначально был дублирован как таковой Олафа Кирха в должности в fa.linux.security группы новостей. Встраивая NULL-байты / символы в приложения, которые не обрабатывают должным образом постфиксные терминаторы NULL, злоумышленник может использовать систему, используя такие методы, как включение локальных файлов . Эксплойт Poison Null Byte использует преимущества строк известной длины, которые могут содержать нулевые байты, и независимо от того, использует ли атакованный API-интерфейс строки с нулевым завершением. Помещая байт NULL в строку в определенный байт, строка заканчивается в этой точке, обнуляя оставшуюся часть строки, например расширение файла.

Строгость

Эксплойт Вероятность

эксплуатация

Завершение имени файла в строке, например, расширение файла.
Завершение или комментирование оператора SQL при динамическом выполнении, например, Oracle EXECUTE IMMEDIATE.

Perl PHP Null Byte Injection

rain.forest.puppy в выпуске Phrack 55 рассказал об использовании NUL Byte Injection в Perl и о том, как их можно использовать. Результаты были очень похожи в PHP.

Ниже приведен пример уязвимого PHP-скрипта с нулевым байтом:

$ file = $ _GET [ 'file' ] ; require_once ( "/ var / www / $ file .php" ) ;

Хотя приведенный выше сценарий защищен путем принудительного расширения файла «.php», его можно использовать следующим образом:

Вышеуказанное внедрение байтов NULL приведет к удалению обязательного расширения добавляемого файла (.php) и загрузке файла / etc / passwd.

Adobe PDF ActiveX Null Byte Attack

Использование уязвимости переполнения буфера в компоненте ActiveX, поставляемом с Acrobat / Acrobat Reader от Adobe Systems Inc., позволяет удаленным злоумышленникам выполнять произвольный код.

Проблема, в частности, возникает при получении ссылки в следующей форме:

Где [длинная строка] — это длинная строка, созданная вредоносным ПО, содержащая допустимые символы URI. Запрос должен быть отправлен на веб-сервер, который усекает запрос до нулевого байта (% 00), в противном случае указывается недопустимое имя файла и возвращается страница «файл не найден». Примеры веб-серверов, которые усекают запрошенный URI, включают Microsoft IIS и Netscape Enterprise. Хотя запрашиваемый URI усекается для целей поиска файла, длинная строка по-прежнему передается в компонент Adobe ActiveX, отвечающий за отображение страницы. Это, в свою очередь, вызывает переполнение буфера в RTLHeapFree (), позволяя злоумышленнику перезаписать произвольное слово в памяти. Ответственные инструкции от RTLHeapFree () показаны здесь:

0x44F83AE5 MOV EAX , [ EDI + 8 ] 0x44F83AE8 MOV ECX , [ EDI + C ] . 0x44F83AED MOV [ ECX ] , EAX

EDI регистра содержит указатель на предоставленную пользователем строку. Таким образом, злоумышленник контролирует регистры ECX и EAX, используемые в показанной инструкции MOV.

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

Злоумышленнику не нужно создавать вредоносный веб-сайт, так как его использование может происходить путем добавления вредоносного содержимого в конец любой встроенной ссылки и ссылки на любой веб-сервер Microsoft IIS или Netscape Enterprise. Нажатие на прямую вредоносную ссылку также не требуется, поскольку она может быть встроена в тег IMAGE, IFRAME или скрипт автозагрузки.

Успешная эксплуатация требует, чтобы полезная нагрузка была написана так, чтобы определенные области ввода были приемлемыми для URI. Это включает в себя начальные введенные инструкции, а также некоторые перезаписанные адреса. Это увеличивает сложность успешной эксплуатации. Хотя это не тривиально, эксплуатация определенно правдоподобна.

Java Null Byte Injection

В конце 2007 года Аршан Дабирсиаги провел ограниченное исследование, в котором описал инъекции нулевого байта в Java. Аршан обнаружил два метода, которые Java неправильно обрабатывает NULL-байт.

Следующий код был выделен на веб-сайте Arshan как уязвимый:

Строка path_to_file = запрос. getParameter ( "target" ) + ".xls" ; Файл f = новый файл ( path_to_file ) ;  delivery_to_user ( contentsOf ( f ) ) ;

В аналогичном коде PHP / C / C ++ можно было бы быстро использовать печально известный нулевой байтовый ядр для просмотра любого произвольного файла в системе. Но это также работает в Java, потому что File (file_path) передает пользовательский ввод в open (1) или его эквивалент Windows, который написан на C.

См. Контрольный пример Аршана для получения дополнительной информации.

.NET Null Byte Injection

В нескольких разделах пространства имен .NET есть несколько функций .NET, которые уязвимы для атак Poison Null Byte. Когда .NET CLR не обрабатывает предоставленные пользователем нулевые байты должным образом, могут произойти успешные инъекции.

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

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

Существует ряд известных функций .NET, которые уязвимы для нулевых байт-инъекций:

Server.MapPath завершит любую возвращаемую строку, когда байт Null введен в параметре имени файла, таким образом обнуляя любые данные, добавленные к пользовательскому вводу.

Ниже приведен пример внедрения нулевого байта Server.MapPath, использованного Полом Крейгом в его оценке внедрения нулевого байта .NET :

Sub Page_Load ( ) тусклое имя в качестве строки тусклого REALNAME как строки имя = запрос ( "имя" ) и ".uploaded" RealName = MapPath ( "" ) & "\" & имя ответ . написать ( "Mappath значение переменной name:" & MapPath ( name ) & "
" ) ответ ."Реальное значение:" & realname & "
" ) End Sub

Если к переменной name добавляется нулевой байт (name = c: \ boot.ini% 00), строка завершается до объединения .uploaded.

Решения

PHP

Есть несколько способов предотвратить инъекции Poison Null Byte в PHP. К ним относится экранирование байта NULL с обратной косой чертой, однако наиболее рекомендуемый способ сделать это — полностью удалить байт с помощью кода, подобного следующему:

$ file = str_replace ( chr ( 0 ) , '' , $ string ) ;

Perl

Как и в PHP, в Perl есть несколько вариантов работы с NUL-инъекциями. Также как и в PHP, рекомендуется не экранировать байт, а полностью удалить его, используя код, подобный следующему:

Adobe

Обновите Adobe до последней версии. Или измените настройки Adobe Acrobat / Acrobat Reader, чтобы файлы PDF не открывались автоматически при доступе через веб-браузер. При появлении запроса сначала сохраните файл на диск, прежде чем открывать, тем самым закрывая описанный вектор эксплуатации.

Это можно сделать, используя следующие шаги:

1. Open Adobe Acrobat/Acrobat Reader 2. Go to Edit —> Preferences 3. Uncheck the «Display PDF in browser» setting 4. Click OK

.NET

Проблемы .NET были исправлены следующими исправлениями:

KB928365 (Обновление безопасности для Microsoft .NET Framework 2.0)

KB928366 (Обновление безопасности для Microsoft .NET Framework 1.1)

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

Источник

Нулевой байт (Null Byte Injection, Null Byte Poisoning attack) в Java, Perl, PHP

Для начала разберёмся что такое нулевой байт(%00, 0x00, null byte), откуда он появился и зачем собственно он нужен. Для этого придётся немного вспомнить как представляются строки в C. Строка в C – это набор символов или точнее байтов, которые оканчиваются нулевым байтом (‘\0’). Такие строки получили названия C Strings или нуль-терминированные строки. В таком представлении строк нулевой байт необходим для опознавания конца строки.

Давайте представим ситуацию, что в заполненную строку длинной в n символов мы впишем ‘\0’ на место символа n/2. Теперь, C-функции для работы со строками (strlen, strcpy..) просто не будут видеть “мнимую часть”, она как бы больше не существует. Байты, следующие за null байтом игнорируются. Казалось бы ну и чёрт с ним, и такая реакция полностью оправдана, если такая ситуация встречается в программе написанной на C/C++. А вот если программа написана на языках разработки веб-приложений, таких как Java (JSP), Perl, PHP – то это может грозить нам неприятностями.

В Java, Perl и PHP строки хоть и не представлены в виде нуль-терминированных, однако, не стоит забывать, что работа на системном уровне представлена в этих языках через C/C++ функции. Из-за чего и возникает опасность атак с использованием нулевого байта (Null Byte Injection, Null Byte Poisoning attack).

Рассмотрим пример уязвимого Perl скрипта. Переменная получаемая из переданного запроса недостаточно грамотно проверяется на метасимволы. В итоге загрязнённые данные поступают в системную функцию open(), которая реализована на C, поэтому при использовании %00 игнорируется казалось бы предопредлённый формат файла (JPG).

. $buffer = $ENV; $buffer =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg; $fn = '/home/userx/data/' .$buffer. '.jpg'; open (FILE,"<$fn"); .

Обычный запрос: …/script.pl?page=userphoto
Небезопасный запрос: …/script.pl?page=../../../../etc/passwd%00

. $file = $_GET['file']; require_once("/var/www/images/$file.dat"); .

Обычный запрос: …/script.php?file=myprofile
Небезопасный запрос: …/script.php?file=../../../etc/passwd%00

//теперь вылечим $string = str_replace( chr( 0 ), '', $string );

Также в PHP некоторые внутренние функции (функции для работы с регулярными выражениями) обрабатывают строки, как C-Strings: ereg, eregi, ereg_replace, eregi_replace, split, spliti, sql_regcase, mb_ereg, mb_eregi_replace и т.п. Незнание этого ньюанса может сильно испортить жизнь web-программисту.
Нижеследующий код дает злоумышленнику большое поле для деятельности:

$text = (string)@$_GET['text']; if (!ereg('<|>|&', $text)) echo $text;

Фактически, это полноценная XSS уязвимость (XSS атака – Сross Site Sсripting или межсайтовый скриптинг). А уж придумать как использовать эту XSS дыру не составит большой сложности.

В Java в некоторых функциях тоже имеются схожие уязвимости. Например, в конструкторе класса File(String file) из модуля java.io.File конструктор передаёт принимаемое на вход значение в C-функцию. Рассмотрим наш пример. Пользователь запрашивает доступ к определённому файлу, который имеет расширение ‘.db’ При этом в программе проверяется передаваемая строка: и если строка завершается расширением ‘.db’, тогда создается объект класса File и данные считаются из файла для последующего вывода.

. String fn = request.getParameter("fn"); if (fn.endsWith(".db"))

Comments

Warning: count(): Parameter must be an array or an object that implements Countable in /var/www/dezhik.ru/wp-includes/class-wp-comment-query.php on line 399