Доброе время суток, дорогие господа Без лишней воды перейду сразу к делу. Знаю что основной поток шеллов идет с брута+заливка через уязвимости Первый метод дает 100% результат, шеллы всегда есть, но в основном нулевка или что-то уж очень слабое, поэтому перехожу сразу ко второму варианту. Уязвимости, кто как серчит на их наличие?(Под CMS Wordpress, хотя алгоритм поиска отличаться особо не должен для Джумлы, и т.д.) Как это делал я: 1)Развернул вп на локалке 2)Скачал 10-15 рандомных плагинов(В последние разы искал специально по тегам upload) для наличия формы.(Для багов типа Arbitrary File Upload) 3)Прошелся по ним рипсом(Rips PHP code scanner) на наличие опасных фунок, далее смотрю сам - если есть что-то подозрительное - запускаю IDE и смотрю что там не так. 4)Тут и начинаются проблемы. Большинство разрабов хорошо чекают файлы для заливки, вайтлисты там всякие, которые уже в 100 раз усложняют заливку. Встречался мне даже разраб, который прикрутил создание своего htaccess в каждой новой папке с залитыми картинками/файлами(Это при том, что им давались другие имена) Тобишь уязвимых плагинов просто не могу найти, и это при том, что я не беру флагманов на осмотр, а беру в основном мелкие плагины до 1к установок. При этом когда захожу на любой баг трекер - смотрю и даюсь диву - там почти в каждом хакнутом плагине разраб вообще не чекает ничего, и это в премиум плагинах/плагинах с 1к+ установок. Все что мне удалось найти таким образом: 1)Одна LFI уязвимость. 300 установок,ага 2)SQLi в хорошем плагине с 3к установок. Параметр передавался в чистом виде, без всяких фильтраций из GET запроса, прямо-таки классика. Но мне не удалось активировать функционал, при котором срабатывает условия для выполнения этого самого запроса, тут я совсем духом упал.(Как быть в таком случае, изучать функционал плагина?) 3)Парочка XSS Усе, это при том что поиск занимает немалое кол-во времени. Так вот, господа матерые, может кто поделиться своими маленькими наработками для серчинга данных вещей? Вот вопросы: -Какие выбирать плагины на сайте WP(новые, старые, с большим кол-вом установок/маленьким) -Когда изучал сорцы паблик сплойтов, то видел как некоторые ребятки заливали свои файлы в обход всех разрабовских чеков(Хоть там вайтлист, проверка на клиенте, майм тип и т.д.) - они все равно грузили через AJAX. Тобишь просто передали в параметр файл, вуаля - он залит. Это как происходит? Где можно почитать?(Плохо знаком с JS, в планах выучить, уж больно он мне не нравится)) -Знаю что аудиту кода научится по книжкам/гайдам нереально, но может есть какие-то материалы/уроки/статьи по теме. Может сесть и плотно начать изучать структуру WP? Поможет ли данный вариант? -Или во всем "виновата" удача?) Заранее благодарен за любые ответы!)
Брать надо милионщика, несколько крайних версий. Сравнивать между собой, и смотреть где что заткнули, а потом пробиваться к дыре. Для примера закидываю, как сравнивал 4.6.1 и 4.6.0 Для начала сравним список файлов: cd ./wordpress-4.6.1 find ./ > ../bug-research/4.6.1.fnl cd ../wordpress-4.6.0 find ./ > ../bug-research/4.6.0.fnl cd ../bug-research/ diff 4.6.1.fnl 4.6.0.fnl В новой версии появился файлик: ./wp-content/plugins/akismet/class.akismet-cli.php cd wordpress-4.6.0/ cat ../bug-research/4.6.0.fnl | xargs md5sum > ../bug-research/4.6.0.md5.fnl cd ../wordpress-4.6.1/ cat ../bug-research/4.6.0.fnl | xargs md5sum > ../bug-research/4.6.1.md5.fnl cd ../bug-research diff 4.6.1.md5.fnl 4.6.0.md5.fnl > ./md5.diff Уберём строки дубли и все файлы кроме php скриптов cat ./md5.diff | grep \.php | grep ^\< > php.md5.fnl php -r '$a=file("./php.md5.fnl"); foreach($a as $s) echo(substr($s,36));' > php.fnl mkdir fnl mv {4.6.0.fnl,4.6.0.md5.fnl,4.6.1.fnl,4.6.1.md5.fnl,md5.diff,php.fnl,php.md5.fnl} ./fnl/ Сравним сорсы mkdir ./diff ; cd ./diff cat ../fnl/php.fnl | xargs dirname | xargs mkdir -p cat ../fnl/php.fnl | awk '{ print "diff ../../wordpress-4.6.0/"$0" ../../wordpress-4.6.1/"$0" > "$0".diff" }' > ../diff.src.sh . ../diff.src.sh cd .. find ./ | grep \.php.diff Смотрим что к чему less ./diff/wp-admin/includes/class-file-upload-upgrader.php.diff # инклюд? скуля? крос? less ./diff/wp-admin/includes/media.php.diff # скуля? крос? less ./diff/wp-content/plugins/akismet/class.akismet-admin.php.diff # ??? less ./diff/wp-content/plugins/akismet/class.akismet.php.diff # скуля? less ./diff/wp-content/plugins/akismet/views/config.php.diff # скулёжная параноя? less ./diff/wp-includes/class-http.php.diff # скуля? less ./diff/wp-includes/wp-db.php.diff # глюк? less ./diff/wp-includes/revision.php.diff # глюк? less ./diff/wp-includes/pluggable.php.diff # глюк? less ./diff/wp-includes/script-loader.php.diff # крос? less ./diff/wp-includes/load.php.diff # глюк? Удачи!
Спасибо огромное за столь подробное разъяснение, но у меня теперь больше вопросов, чем их было до вашего поста Рад что откликнулся действительно толковый и знающий человек. Для рисерча именно самого двига - это хороший вариант, мы мониторим все нововведения в коде, но как это может помочь в случае с плагинами? На данный момент для WP их насчитывается 43к, неужели все они уже просмотрены и не содержат уязвимостей, из-за чего нам надо шустрить только их апдейты? Впринципе, для крупных плагинов такая стратегия тоже вполне подходит, хотя их тоже тысячи, теоретически, в каком-то хоть одном уязвимость да найдется даже сейчас, не обязательно же ждать апдейтов. Вы уж простите меня за может быть плоское мышление, но работа с многомиллионными плагинами - мне пока что не по силам. Я знаю что успешно ломают плагины и с 3к инсталлов, и c 1к. Мне повезло общаться с очень крутым чуваком(тут его наверное не знают, он на экспе сидел,сейчас без понятия), я ему обязан всеми базовыми знаниями в этой области(с чего начинать, где читать, где покупать, и т.д.), но не суть. Я потерял свою жабу, а он засел в приват - теперь так просто жабу у него не получить) Кробка, если ты читаешь это - скинь свою жабу плез Так вот, к чему я это, как-то раз - у него был производственный день - он выкачал абсолютно все плагины вордпресса, потом прогнал их на опасные функции своими скриптами(Естесна подводные камни и подробности он мне не палил) - за пару дней у него получилось найти около 3-4 0day, один вроде как Race Condition с удалением файла через время определенное, другой был в очень плотном плагине, но только от админа(Я такой тоже находил), и еще более мелкие. Сколько раз пробовал работать по его методе - ниче путного не выходило, не знаю. Может у меня знаний нехватает, или терпения. Ну, спасибо огромное что осилили мою стену текста, ответили и поддержали беседу. Буду рад если ответите на мои новые вопросы!)
Тоже придерживаюсь подобной методике, тут нужно понимать саму природу уязвимостей, т.е имеет смысл изучить функции пхп, какие могут привести к RCE, инклуду и т.д. Естественно, также, имеет смысл написать свой скриптик для автоматизации поиска по регулярным выражениям, а там уже анализировать структуру вызова, самое вкусное тут наверное - это набор этих регулярок, за всем не уследишь, а профитные показывают результат!!!
Кому как, кто-то мойвой питается( и хватает ), кто-то тюленей жрёт, а вот косатки могут и кита затопить. Однажды сел я пробивать какой-нибудь цымес, думаю: "Возьму что по легче, с версией 1, и чтобы кода не три тонны с гаком."( помню это была борда, тока название забыл ) Всю её облазил, код чистый и ясный, как слеза комсомолки. Отчаяние охватило меня, нету дыр хоть тресни, видно что нету. Помню даже забил на неё и решил считать не пробиваемой. Но спустя неделю, хер знает почему и как, снова полез в ней копаться, и натолкнулся на такую фигню как дэфолтный пароль( он там тоже как-то не явно присутвовал ). Что бы шел залить пришлось повозится, помню как-то хитро приходилось сохранять конфиг. Гуглил не особо стартараясь, и таки наковырял себе полтиничек нулёвок. Каждый решает сам на какой глубине ему плавать, но чем глубже - тем сильнее давит череп. Вообще, дыры надо пробивать автоматом с ручным управлением, а не лазить по портянкам с красными глазами. Ведь что по сути представляет из себя код - дерево, в котором при одних условиях ты поподаешь на ветку, а при других нет( иногда могут скинуть с дерева ). Даже где-то встречал набор скриптов, от паренька со славянской фамилией, который строит по исходникам абстрактное дерево кода. По сути роль автомата( называю его "gblpokoJL" ) сводится к следующему: он запускает исследуемый скрипт, встречает ветвление, и меняя входные данные пытается пройти во все ветвления если у него возникают трудности он обращается к оператору, если встречает на пути сладкую функу подаёт сигнал оператору. Проблема не в том чтобы сладеньких найти, проблема их исполнить. Ну найдёшъ file_put_contents( $file, $txt ); а она внутри функи, а функа в классе, а класс создается где-то в середине портянки, а портянку можно исполнить только если объявлена мегаконстанта. Короче: игла в яйце, яйцо у зайца, заяц в гробу, гроб на дереве, а дервьев тьма и все в гробах. Случайно натолкнулся phpdbg( вроде ничо, но тоже не то ), думал что, кроме говна x-debug, и нет ничего. Короче, в phpdbg я увидел во что превращается сорс и тут я понял что раз есть ассемблер надо копать в него и искать дыры на стыке кода и исполнителя, но дырокол можно cделать из phpdbg и той фигни которая деревья создаёт. Запомните: "Cамые жирные дыры ждут в самом запутаном коде, и живут в его дебрях."
