Всім давно відомо, що найчастіше c допомогою XSS атакуючий намагається відправити Cookie жертви, прочитати CSRF токени, провести фішингову атаку (створивши фальшиву форму логіна), здійснити яку-небудь дію від імені користувача та деякі інші близькі за метою атаки (можливо, це не всі можливості, але це все найбільш популярні відомі мені на даний момент).
У цій статті хочу поділитися ще одним способом отримати вигоду від XSS, яким можна доповнити даний список. Треба відзначити, що у цього способу є один плюс - він не взаємозамінні попередні, тобто його можна використовувати після всіх вище перерахованих, як доповнення.
Мета цього методу - моніторити сторінки від імені користувача, за якими він переходить на атакується сайті, а також моніторити його натискання клавіш (можна ще руху і кліки мишкою, але на мене так це буде зайвою, не особливо корисною інфою, в більшості випадків точно) .
Тепер з приводу максимальної користі - я вважаю, що алгоритм буде таким:
Все опціональні пункти списку имхо повинні виконуватися в залежності від ситуації і конкретних пріоритетах з метою, яких треба досягти за допомогою XSS, вони іноді можуть заважати один одному (якщо спробувати їх скомбінувати, точніше виконати один за іншим) і збільшують ймовірність провалу експлуатації XSS.
Але ось перший і останній пункти виконувати варто завжди, при будь-якому раскладе.Собственно основна частина статті буде про останній пункт з цього списку.
Підходимо до мети.
ми позбавимо його цієї можливості.
Позначаємо ідею.
Тільки у даного методу є обмеження, а саме - він не буде працювати, якщо у відповідях веб-сервера сайту є заголовок X-Frame-Options зі значенням DENY. Але особисто я такі сайти зустрічав буквально пару раз, зараз навіть у половини SAMEORIGIN НЕ виставлено, не кажучи вже про повне обмеження через DENY.
Аналізуємо ідею.
Як було згадано вище - вирішив запозичити у BeEF'a класну ідею черзі виконання команд. Наприклад, були проаналізовані сторінки, які скинув бот, коли привілейовані юзер лазив у себе в панелі управління з stored XSS, ми залишаємо боту команди - JS-код, типу в наступний раз коли користувач зайде, натисни цю кнопку, запиши сюди таке значення і тд , коли цей користувач наступного разу заходить на сторінку, бот читає команди і виконує їх, а нам в усі не обов'язково бути у його штурвала - дуже зручно.
В основному такий бот, звичайно розрахований для статусних користувачів якихось сайтів, у яких є додаткові "важелі" управління контентом, іншими користувачами і тд. З запитів по функціоналу видно, що без серверної частини не обійтися.
Реалізуємо ідею.
Дану частину статті в принципі можна пропустити, так як вона просто описує процес реалізації потрібного бота і деякі його деталі, на випадок, якщо хтось захоче його переробити або допив під себе. Хоча у бота на початку коду будуть змінні, через які можна виставити деякі настройки.
Спочатку алгоритм дій бота з моменту завантаження:
1) Перевірка наявності заголовка X-Frame-Options: DENY (якщо є, то згортаємо вудки);
2) Вбудовування фрейма і налаштування всіх компонентів бота;
3) Видалення скрипта і всіх слідів в HTML-коді;
4) Налагодження контакту з сверверной частиною і початок перессилкі даними, реагуючи на відповіді (отримуючи від сервера команди);
Перший пункт зробив не зовсім повноцінно, тобто бот перевіряє тільки першу сторінку і кореневу заголовка. Справа в тому, що зазвичай ці заголовки вбудовуються веб-сервером і для всіх сторінок відразу і дуже рідко, що для окремої сторінки все робиться "вручну". Та й цей заголовок сам по собі досить рідкісний. Ну а по другому і третьому особливо говорити нічого, нижче все буде.
Але про всяк випадок в коді бота реалізована можливість детектив такий фреймовой рекурсії і запобігання при першій же спробі додавання фрейма в уже створений, але краще не сподіватися тільки на неї, а додатково видаляти код перед завантаженням коду бота. Хоча я проблем ще не зустрічав.
Відправка HTML-коду сторінки.
Ідея вже була реалізована деякими ентузіастами, але для мене їх напрацювання не підходили, хоча б тому що більшість з них були досить простими, тобто детектив код натиснутоюклавіші і черезString.fromCharCode переводили в символи. Але у такого методу ряд недоліків - керуючі клавіші типу шифт, контрола, пробілу та ін, не перекладаються ні в який вид (часто просто в порожній символ), взаємодія цифро-буквених клавіш з шифтом некоректно логіруется, так як це треба реалізовувати програмно, а також всі натиснуті клавіші відображаються у верхньому регістрі, що теж виправляти програмно.
В результаті вийшов кейлоггер, який коректно детектив все клавіші цифр, букв і основних знаків, працюючи на обох розкладках, реагую на шифт і логгіруя всі основні спеціальні клавіші. Правда деякі знаки (у верхній частині цифрового ряду, які друкуються при натиснутому шифт і цифрі), на деяких машинах можуть відрізнятися, так як були реалізовані за основними стандартом, які деяким деякі компанії змінюють.
Кожна порція натиснутих символів зберігається у клієнта до тих пір, поки текстовий елемент не втратить фокус. Далі ця порція відправляється на сервер, де зберігається в текстовому файлі, який також буде створюватися кожен день з новою копією, щоб не було зростання до великих розмірів і можна було швидко знайти, що юзер набирав в такий час.
По мимо самих клавіш на сервер відправляється з кожною порцією інформація про елемент, в якому набирався текст (тобто чи був це.