CVE-2018-6389 PoC — WordPress 安全漏洞

Source

Associated Vulnerability

Description

CVE-2018-6389 PoC node js multisite with proxy

Readme

# CVE-2018-6389 PoC node js multisite with proxy

![alt text](Desislava_Petkova.png "Живко ни са прай ей!")

Този скрипт е базиран на CVE-2018-6389, доста коварен проблем на Wordpress, който за жалост вероятно няма да бъде отстранен от екипа, който разработва платформата въпреки, че е известен от доста време.

***!!! ВАЖНО ПРЕДИ ДА ПРОДЪЛЖИШ !!!
Цялото репо и информация споделена тук е свободна за ползване под всякаква форма - копиране, надграждане, променяне с цел надграждане или други цели, както и споделяне. Използването на споделената информация за цели, различни от обучителни, с цел експеримент и/или да защитите собствена платформа, базирана на Wordpress вероятно е в противоречие с редица закони, с които не съм запознат. Не използвайте скрипта с цел атака на сайтове! Аз не нося отговорност за вашите действия. Използвайки го се съгласявате с тези условия. DDoS атака (отказ от услуга) насочени към сайт, който не е ваша собственост, може да се възприеме като терористична атака. 
!!! УБЕДЕТЕ СЕ, ЧЕ СТЕ АБСОЛЮТНО СИГУРНИ В ДЕЙСТВИЯТА СИ И ПОМИСЛЕТЕ ДОБРЕ ПРЕДИ ДА ПРОДЪЛЖИТЕ !!!***

Скрипта го написах отдавна, но понеже знам, че сте много готини, реших да ви го споделя. Използвайте го по предназначение! Наистина...

### За какво иде реч

В мрежата има много информация по темата, както и няколко готови скрипта, най-често написани на python като [Shiva](https://github.com/s0md3v/Shiva) и [този](https://github.com/WazeHell/CVE-2018-6389), от които почерпих доста вдъхновение, когато го писах, с които също може да тествате тази "слабост" в изолирана среда, но понеже аз съм "сейрджия", реших да добавя няколко "благинки". 

[Тук](https://thehackernews.com/2018/02/wordpress-dos-exploit.html) може да прочетете един интересен блог по тематата

На кратко, ако заредите [https://your-wordpress-site.com/wp-admin/load-scripts.php?c=1&load=editor,common,user-profile,media-widgets,media-gallery](https://your-wordpress-site.com/wp-admin/load-scripts.php?c=1&load=editor,common,user-profile,media-widgets,media-gallery) (като разбира се промените линка така, че да сочи към вашата инстанция) и това, което ви се появи на екрана е "некаф js бате", то със сайта има проблем. Всеки изброен параметър в query string-а, е име на файл, който не е в кеш. Сиреч прави IO операция за всеки файл от диска, събира ги в един и го връща към клиента. Но файловете са си доста. Доста повече, октолкото ресурс се изисква за да го заявиш няколко пъти. Да кажем, че с един лаптоп и 50-ина mb down link, 30-ина сайта със средна хубост - хостинг, издържат 20-30 секунди, преди окончателно да издъхнат.

### Други изисквания

 - NodeJS 8.11.2
 - Работеща Wordpress инстанция/и.
 - Изисква се да си направите съвсем лесна проверка на отделните проксита, на машина, която е достъпнa през интернет. GET заявка, на която се връща като стринг IP адреса, от който вашият сървър вижда заявката. Не всички прокси сървъри са "анонимни"! Също тази процедура валидира, че проксито работи, преди да започне самата атака.

### Структура:

 - Файлът websites.js съдържа списък със сайтове - "жертви", от който без да искам съм забравил да махна няколко останали, за които знам със сигурност, че са податливи при контакт със скрипта. Заклевам се, че никога не съм го пробвал, просто така си мисля.

 - Файлът userAgents.js съдържа списък с user-agents, които се избират на случаен принцип при всяка отделна заявка към жертвите.

 - fileList.js съдържа списък със отделните файлове, които да бъдат заредени от "жертвата", с цел при актуализация на Wordpres, лесно да може да се добавят, коригират.


 - В index.js е и самият скрипт за изпълнение.

### Параметри

 - countries е масив от държави, от които да се търсят проксита. (от кои държави да идват атакита, през проксита)
 - wanCheckUrl е пълният адрес до който скрипта ще се допита и "огледа" дали не е през прозрачно прокси.
 - requestTimeout е времето в милисекунди, за което едно прокси ще се счита за неработещо в случай, че не се е свързал.
 - maxRequests лимит на заявките от машината към "жертвите". Прекалено голямо число, може значително да натовари и вашата машина. Около 30 паралелни заявки са нужни, за един сайт на mid-level хостинг.

### Процедура:

 - Скрипта се допитва до автоматичната проверка за прокси и записва IP адреса, с който е видим в публичното пространство.
 - Започва да търси свободни проксита от всевъзможни публични списъци.
 - При появата на всеки един се прави заявка към автоматичната проверка за прокси и ако адреса с който нашият сървис отговори, е различен от първият път, то проксито се записва в масив и започва изпълнение на атаката.
 - Долу-горе скрипта върти жертвите през всяко прокси на принципа round-robin и няма нищо специално в логиката, просто прави възможно най-много заявки, през възможно най-много различни и работещи проксита.

 > В конзолата се извежда в цвят информация за всяка "жертва" поотделно и тези, които са под DDoS се оцветяват в червено.

```sh
npm install
//редактирай webstites.js
node index.js
```

### Google Dork за "жертви"
 > inurl: “wp-admin/load-scripts.php”

***Реших да посветя този скрипт на любимата ми телевизия tvsz, защото знам, че са ми големи "почитатели" и най-вече, защото ще намерят линка на сайта си, в моят списък. Смисъл ще им вдигна малко рейтинга, да им върна стара "услуга". Също, използвам случая и да поздравя татко, който вчера имаше имен ден, но не ми остана време да му се обадя.***

File Snapshot

 [4.0K]  /data/pocs/695ebf71999abc70f2c3298bf3ed4cdc27cff9ff
├── [251K]  Desislava_Petkova.png
├── [3.3K]  fileList.js
├── [6.2K]  index.js
├── [ 630]  listener.js
├── [ 404]  package.json
├── [ 53K]  package-lock.json
├── [8.7K]  README.md
├── [1.4K]  userAgents.js
└── [ 734]  websites.js

0 directories, 9 files

Remarks