Страдания из за WordPress...

[Ангел]

Здравствуйте, уважаемое сообщество! Помогите пожалуйста разобраться с вордпресом версии 6.1.6. Мне нужно получить доступ к базе данных конкретно через уязвимые плагины, их оочень много и вот самые основные уязвимости:

1. Эта уязвимость относится к плагину WordPress Ditty, и она заключается в отсутствии проверки авторизации для функции save_ditty_permissions_check в версиях ниже 3.1.25.

Описание уязвимости:
Название: Недостаточная проверка авторизации (Missing Authorization).
Затронутая версия: Все версии плагина Ditty до 3.1.25.
CVE ID: CVE-2023-47764.

2. уязвимости в плагине WordPress под названиемFluentForm, версия до 5.0.0, которая подвержена SQL-инъекции.

3. Эта уязвимость касается плагина Slider Revolution версий до 6.7.0 и связана с отсутствием авторизации для определенных действий.

4. Эта уязвимость касается плагина TablePress версий до 2.4.3 и представляет собой XXE-инъекцию(XML External Entity).

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

 

[c0d3x]

Если под эти CVE нет публично доступных PoC/PoE, то единственный возможный вариант это ставить себе эту версию WP + эти же версии плагинов, и рядом ставить следующие версии всего этого, с апдейтами, и искать отличия в коде, пробовать ручками ковырять. Разумеется для этого требуется знание PHP, как минимум.

 

[zdestuta]

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

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

что важно понимать: наличие установленного уязвимого плагина вовсе не гарантирует, что все-все его actions куда-то подклбючены (вот тут про основы программирования, CFG - control flow graph, а также reachability конкретной точки CFG бы понаписать, да вот увы лень) и туда можно payload засовать.
ну это как ты залез грабить, просто узнав (подсмотрев) что замок такой-то модели "уязвимый", саму дверь то открыл, а дальше внезапно стенка кирпичная - упс... они самовольно (да даже по дурости может) сделали перепланировку внутри, нигде этого не указав!

дабы прям конкретно так убедиться ломается эта связка WP движка и плагина именно в этой конфигурации, как тут уже правильно писали выше обычно рекомендуется не верить wpscan'у на слово (никто не отменял false positives ведь! любые сканеры они "подсказчики", а не гаранты), а прям в VM поставить данную конфигурацию и посмотреть чего там вызывается (прям debug, ну или логировать. чтобы понять чего на стороне WP происходит, куда твой payload попадает и как и где обрабатывается) - для этого понадобится базовое знание PHP и архитектуры WordPress (какие ендпоинты, как что includ'ится, как вызываются обработчики actions, etc.) а также навыки отладки и логирования PHP кода.

ещё один важный плюс такого подхода (ломать локальный стэнд на VM) в том, что ты не нашумишь на таргете, так как шум на таргете может привлечь админов и они даже потенциальную дырку "на всякий случай" заделают просто нажав кнопку "обновить все плагины и WP" - им это действие гораздо проще и быстрее выполнить, чем тебе провести сканы и исследования.

написанное выше - справедливо не только для WP, но и вообще для любых и web и не-web систем, в плане взлома конечно же.

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

 

[zdestuta]

Помогите пожалуйста разобраться с вордпресом версии 6.1.6.

отставить "страдать" !

вот 146% простой, понятный и надёжный как каменный топор метод хака ("бесплалевный" для таргета, что полезно - позволяет избежать "излишнего шума" в логах таргета) прям любой почти хрени:
1. поднимаешь локально вебсервер и БД чётко прям версии как на таргете (рекомендую Docker контейнер - это быстро и просто, 5 минут)
2. сетапишь там CMS и уязвимые плагины все - всё чётко тех же версий как на таргете
3. делаешь сайт тупо на одной странице всё чтобы доступно было, очень упрощённый "таргет" с хорошим reachability внутренностей на бэкэнде
4. в коде где "ну походу по описанию уязвимость тут" - ставишь логирование - тупо "print" какой-нибудь чтобы в логах вебсервера видно результат было
5. юзаешь это дело отправляя пэйлоады и смотришь логи вебсервер - для начала на предмет "а оно вообще туда попадает?" (если код достижим извне, то твой "print" сработает ну хотя бы "ya tuta" напишет в логах сервера) - это фаза "пациент ну хотя бы захавал пилюлю и я вижу она где надо в его желудке!"
6. если ты добился ответа "да! я вижу это в логах!" в предыдущем пункте, тогда начинаешь логировать и пэйлоад в каком виде он долетает до уязвимой части кода и пытаешься сделать так, чтобы пэйлоад оказал нужный эффект - а это фаза "пилюля вызвала у пациента нужный мне эффект!"
7. и вот когда ты понял чего (какой именно payload) надо отправлять и куда это прилетит "во внутрях" и где "кривизна рук разработчика" (уязвимость) оказалась - вот только тогда пишешь сплоит (часто это тупо curl строчка HTTP запроса с нужными параметрами), тестишь опять локально, ну и после этого имеешь таргер одним чётким "снайперским выстрелом" чтобы админы даже не успели чухнуть что произошло.

скажешь "это сложно" ? да, сложно! кто ж спорит то... но именно этим методом и ломают практически "с гарантией".

это и есть настоящая работа хакера, а не хаотично подбирать сплоиты и не разбираясь тут же запускать их прям простив таргета "в надежде", что что-то сработает (ну так конечно можно тоже делать и многие если не все так развлекались "в детстве" - я вот не осуждаю такое баловство можно то можно, просто крайне низкопродуктивно)

P.S. Мой любимый анекдот на данную тему:
Препод профессор собирается на природу, где планирует присоединиться к компании друзей и подруг.
Ну и попросил студента 1 курса помочь погрузить всё в машину, ну студент тащит: толстую папку где список телефонов всех студенток всех курсов а также даже недавних выпускниц, ящики водки, шампанского, пива, ленты презервативов, пачки виагры, флаконы афродизиаков...
И тут студент обделённый женским вниманием (в силу юного возраста и отсутствия опыта) не выдерживает и стесняясь спрашивает:
- Профессор... а... (заикаясь) ... я так полагаю там будут красивые женщины и Вы взяли всё это вот в надежде на секс?
- Как Вам не стыдно, молодой человек!
- (краснея) Ой, простите, профессор!
- Молой человек, "в надежде" можете Вы пытаться - ведь у Вас времени ещё много впереди! А я уже не молод, поэтому я туда еду не "а надежде", а запасшись всем-всем необходимым и в твёрдой 100% уверенности, что я там точно хоть какую-то студенточку да вы@бу!

 

[Ангел]

отставить "страдать" !

вот 146% простой, понятный и надёжный как каменный топор метод хака ("бесплалевный" для таргета, что полезно - позволяет избежать "излишнего шума" в логах таргета) прям любой почти хрени:
1. поднимаешь локально вебсервер и БД чётко прям версии как на таргете (рекомендую Docker контейнер - это быстро и просто, 5 минут)
2. сетапишь там CMS и уязвимые плагины все - всё чётко тех же версий как на таргете
3. делаешь сайт тупо на одной странице всё чтобы доступно было, очень упрощённый "таргет" с хорошим reachability внутренностей на бэкэнде
4. в коде где "ну походу по описанию уязвимость тут" - ставишь логирование - тупо "print" какой-нибудь чтобы в логах вебсервера видно результат было
5. юзаешь это дело отправляя пэйлоады и смотришь логи вебсервер - для начала на предмет "а оно вообще туда попадает?" (если код достижим извне, то твой "print" сработает ну хотя бы "ya tuta" напишет в логах сервера) - это фаза "пациент ну хотя бы захавал пилюлю и я вижу она где надо в его желудке!"
6. если ты добился ответа "да! я вижу это в логах!" в предыдущем пункте, тогда начинаешь логировать и пэйлоад в каком виде он долетает до уязвимой части кода и пытаешься сделать так, чтобы пэйлоад оказал нужный эффект - а это фаза "пилюля вызвала у пациента нужный мне эффект!"
7. и вот когда ты понял чего (какой именно payload) надо отправлять и куда это прилетит "во внутрях" и где "кривизна рук разработчика" (уязвимость) оказалась - вот только тогда пишешь сплоит (часто это тупо curl строчка HTTP запроса с нужными параметрами), тестишь опять локально, ну и после этого имеешь таргер одним чётким "снайперским выстрелом" чтобы админы даже не успели чухнуть что произошло.

скажешь "это сложно" ? да, сложно! кто ж спорит то... но именно этим методом и ломают практически "с гарантией".

это и есть настоящая работа хакера, а не хаотично подбирать сплоиты и не разбираясь тут же запускать их прям простив таргета "в надежде", что что-то сработает (ну так конечно можно тоже делать и многие если не все так развлекались "в детстве" - я вот не осуждаю такое баловство можно то можно, просто крайне низкопродуктивно)

P.S. Мой любимый анекдот на данную тему:
Препод профессор собирается на природу, где планирует присоединиться к компании друзей и подруг.
Ну и попросил студента 1 курса помочь погрузить всё в машину, ну студент тащит: толстую папку где список телефонов всех студенток всех курсов а также даже недавних выпускниц, ящики водки, шампанского, пива, ленты презервативов, пачки виагры, флаконы афродизиаков...
И тут студент обделённый женским вниманием (в силу юного возраста и отсутствия опыта) не выдерживает и стесняясь спрашивает:
- Профессор... а... (заикаясь) ... я так полагаю там будут красивые женщины и Вы взяли всё это вот в надежде на секс?
- Как Вам не стыдно, молодой человек!
- (краснея) Ой, простите, профессор!
- Молой человек, "в надежде" можете Вы пытаться - ведь у Вас времени ещё много впереди! А я уже не молод, поэтому я туда еду не "а надежде", а запасшись всем-всем необходимым и в твёрдой 100% уверенности, что я там точно хоть какую-то студенточку да вы@бу!

Спасибо большое за ответ! Я просто новичок в хакерстве, вроде все изучил, а на практике ничего не получается. Буду взламывать сайты по твоему подходу, с чатом гпт точно получится а ты сам также взламываешь сайты? Много ли времени может занять сайт? С анекдота поржал:>

 

[zdestuta]

Спасибо большое за ответ! Я просто новичок в хакерстве, вроде все изучил, а на практике ничего не получается. Буду взламывать сайты по твоему подходу, с чатом гпт точно получится а ты сам также взламываешь сайты? Много ли времени может занять сайт? С анекдота поржал:>

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

сначала ты убеждаешься что пэйлоад долетает до потенциально уязвимой части (ещё есть вариант прям debug'ом идти за пэйлоадом в коде и смотреть как он проваливается и где и как обрабатывается - так вообще 0day находят в том числе) а потом думаешь какой пэйлоад подобрать чтобы оно в ответ или что-то глубого в бэке сделало "не то что ожидал автор" или тебе выплюнуло sensitive information какую-нибудь.

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

 

[zdestuta]

Ангел , чуть не забыл ещё "полезняшку" дать дабы не заблудиться в CFG (Control Flow Graph) любой проги в рантайме есть такая штука как backtrace (она же print call stack) - это что-то типа "ой, а как оно вызывалось-вызывалось из функции другие функции что сюда-то в эту функцию попало?"
Backtrace можно вызывать как при debug'e во время точки останова (breakpoint), так и в рантайме в реальном времени путём логирования.
В общем без backtrace прям "жизнь не жизнь" при ковырянии в коде в рантайме и отладке, особенно если сплоит пишешь (отладка таргета куда попадает и как payload из сплоита)
Ну так вот PHP тут не исключение и на нём тоже можно (нужно!) так ориентироваться по backtrace.

 

[Ангел]

Ангел , чуть не забыл ещё "полезняшку" дать дабы не заблудиться в CFG (Control Flow Graph) любой проги в рантайме есть такая штука как backtrace (она же print call stack) - это что-то типа "ой, а как оно вызывалось-вызывалось из функции другие функции что сюда-то в эту функцию попало?"
Backtrace можно вызывать как при debug'e во время точки останова (breakpoint), так и в рантайме в реальном времени путём логирования.
В общем без backtrace прям "жизнь не жизнь" при ковырянии в коде в рантайме и отладке, особенно если сплоит пишешь (отладка таргета куда попадает и как payload из сплоита)
Ну так вот PHP тут не исключение и на нём тоже можно (нужно!) так ориентироваться по backtrace.

Бро, спасибо большое за годные советы, ты очень помог!

 

[petrinh1988]

ещё один важный плюс такого подхода (ломать локальный стэнд на VM) в том, что ты не нашумишь на таргете, так как шум на таргете может привлечь админов и они даже потенциальную дырку "на всякий случай" заделают просто нажав кнопку "обновить все плагины и WP" - им это действие гораздо проще и быстрее выполнить, чем тебе провести сканы и исследования.

Чтобы нажать кнопку "обновить все плагины в WP", нужно обладать достаточной уверенностью, что после этого действия сайт продолжит работать. Гораздо чаще локльные какие-то реакции. Например, поправить права, убрав возможность записать в файл. Ну это так, просто уточнение.

 

[xargs]

Чтобы нажать кнопку "обновить все плагины в WP", нужно обладать достаточной уверенностью, что после этого действия сайт продолжит работать.

У меня свой сайт на ВП, каждый раз когда я обновляю софт на серваке и двиг, плагины я аж немного потею. Лол совпадение какое, в данный момент пришло сообщение:

ты на сайте ничего не менял?

Менял... обновил 6 плагинов и двиг и сервер софт. Вот опять стили поехали куда-то в сторону.
Каждый раз прежде чем обновить я делаю бэкапы бд и файлов двига, файлов конфигов nginx, php-fpm. Несколько раз секурити обновы сбивали мне сокет который связывает nginx+php, с конфигами nginx тоже были свои приколы. После обновы первым делом я чищу лог ошибок, потом запускаю tail -f error.log и начинаю серфить разные страницы сайта и следить за терминалом, бывает вылазят новые критикалы, приходиться писать разрабам письма чтоб своими костылями не портить, потому что костыль работает ровно до следующей обновы. Так что обновы это еще тот гемор, не всегда конечно но нужно быть готовым и понимать что делать.