Unicode Injection
{{#include ../../banners/hacktricks-training.md}}
Introduction
В залежності від того, як бекенд/фронтенд реагує, коли він отримує дивні юнікодні символи, зловмисник може обійти захист і ввести довільні символи, які можуть бути використані для зловживання вразливостями ін'єкцій, такими як XSS або SQLi.
Unicode Normalization
Нормалізація юнікоду відбувається, коли юнікодні символи нормалізуються до ASCII символів.
Один з поширених сценаріїв цієї вразливості виникає, коли система модифікує якимось чином вхідні дані користувача після їх перевірки. Наприклад, в деяких мовах простий виклик для перетворення входу на верхній або нижній регістр може нормалізувати дані, і юнікод буде перетворено на ASCII, генеруючи нові символи.
Для отримання додаткової інформації перегляньте:
{{#ref}} unicode-normalization.md {{#endref}}
\u to %
Юнікодні символи зазвичай представлені з префіксом \u. Наприклад, символ 㱋 є \u3c4b(перевірте тут). Якщо бекенд перетворює префікс \u на %, отриманий рядок буде %3c4b, що при декодуванні URL є: <4b. І, як ви можете бачити, символ < ін'єковано.
Ви можете використовувати цю техніку для ін'єкції будь-якого символу, якщо бекенд вразливий.
Перевірте https://unicode-explorer.com/, щоб знайти потрібні символи.
Ця вразливість насправді виникає з вразливості, яку виявив дослідник, для більш детального пояснення перегляньте https://www.youtube.com/watch?v=aUsAHb0E7Cg
Emoji Injection
Бекенди поводяться дивно, коли вони отримують емодзі. Саме це сталося в цьому звіті, де дослідник зміг досягти XSS з корисним навантаженням, таким як: 💋img src=x onerror=alert(document.domain)//💛
У цьому випадку помилка полягала в тому, що сервер після видалення шкідливих символів перетворив UTF-8 рядок з Windows-1252 на UTF-8 (в основному кодування вхідних даних і перетворення кодування не збігалися). Тоді це не дає правильного <, а лише дивний юнікодний: ‹
``Отже, вони взяли цей вихід і знову перетворили з UTF-8 на ASCII. Це нормалізувало ‹ до <, так працював експлойт на цій системі.
Ось що сталося:
<?php
$str = isset($_GET["str"]) ? htmlspecialchars($_GET["str"]) : "";
$str = iconv("Windows-1252", "UTF-8", $str);
$str = iconv("UTF-8", "ASCII//TRANSLIT", $str);
echo "String: " . $str;
Списки емодзі:
- https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv
- https://unicode.org/emoji/charts-14.0/full-emoji-list.html
Найкраще/найгірше у Windows
Як пояснено в цьому чудовому пості, Windows має функцію під назвою Найкраще, яка замінює юнікодні символи, які не можуть бути відображені в ASCII-режимі, на подібні. Це може призвести до неочікуваної поведінки, коли бекенд очікує конкретний символ, але отримує інший.
Можна знайти символи найкращого підбору на https://worst.fit/mapping/.
Оскільки Windows зазвичай перетворює юнікодні рядки в ASCII-рядки на одному з останніх етапів виконання (зазвичай переходячи з API з суфіксом "W" до API з суфіксом "A", як GetEnvironmentVariableA і GetEnvironmentVariableW), це дозволяє зловмисникам обходити захист, надсилаючи юнікодні символи, які в останню чергу будуть перетворені в ASCII-символи, що виконуватимуть неочікувані дії.
У блозі пропонуються методи обходу вразливостей, виправлених за допомогою чорного списку символів, експлуатація перетворень шляхів за допомогою символів, відображених на “/“ (0x2F) та символів, відображених на “\“ (0x5C) або навіть обходу захисту оболонки, як escapeshellarg у PHP або subprocess.run у Python, використовуючи список. Це було зроблено, наприклад, використовуючи широкі подвійні лапки (U+FF02) замість подвійних лапок, так що в кінці те, що виглядало як 1 аргумент, було перетворено на 2 аргументи.
Зверніть увагу, що для того, щоб додаток був вразливим, він повинен використовувати "W" Windows API, але в кінці викликати "A" Windows API, щоб було створено "Найкраще" юнікодного рядка.
Кілька виявлених вразливостей не будуть виправлені, оскільки люди не погоджуються, хто має вирішити цю проблему.
{{#include ../../banners/hacktricks-training.md}}