2022-06-24 11:34:30
Local File Inclusion (LFI)Всім привіт! Нещодавно я думав про те що, можливо, я обрав не той напрямок ведення постів про безпеку. Тому, спробуймо поговорити в наступних постах про конкретні атаки, без розповідей про те, як їх автоматизовувати.
Поки снідав, то думав, про яку ж саме розказати, з якої почати... Вирішив взяти щось дуже просте й банальне, але яке інколи є дуже таки серйозною вразливістю. Тому, зустрічайте - LFI!
Який вектор атаки?Local File Inclusion атаки націлені на ті компоненти системи, які динамічно імпортують файли для зображення чи опрацювання цих файлів. І якщо у користувача є спосіб впливати на те, який саме файл завантажується — ви в грі!
Конкретний приклад вразливої системиЩоб простіше було зрозуміти, візьмемо простий приклад з php. Дехто з вас, напевно, памʼятає як раніше робились роутери. У вас є посилання виду
my-site.com/index.php?page=contact. А в самому коді писали щось типу
require($_GET['page']). Тобто, аплікація робить імпорт файлу, шлях до якого контролюється ззовні.
Як експлуатується?В прикладі вище, ми замість
page=contact передаємо
page=/etc/passwd і аплікація залюбки робить імпорт файлу
/etc/passwd і показує його вміст. Таким чином ми реалізовуємо атаку, яка називається Information Disclosure.
Маючи спосіб дивитись зміст файлів на сервері, ми можемо дістати багато цікавої інформації. В тому числі вихідні коди самого вебсервера, що досить часто може призвести до Whitebox Penetration Testing, облегшуючи подальші дії. Наприклад, дістати зміст файлу, в якому зберігаються пари логін:пароль для підключення до бази даних.
А якщо додати протоколи?Експлуатація цієї вразливості працює тільки на файлах, які знаходяться локально. Але є але! Деякі мови програмування та фреймворки, дозволяють робити імпорт не лише файлу типу
/etc/passwd, а й "файлів" які зберігаються віддалено. Тобто, передати умовний
https://google.com це не проблема і в результаті завантажиться гугл.
І ось тут вже можна видумувати багато чого і гратись з цим. Наприклад, якщо на системі встановлено той же PHP, то ви можете використовуючи PHP Filters передавати
php://filter/convert.base64-encode/resource=/path/to/file як шлях. Що призведе до конвертації файлу в base64, який вам покажеться згодом. Це допомагає обходити деякі фільтри.
Або, ви можете зробити
page=expect://whoami й взагалі отримати можливість виконувати команди на сервері
(при наявності expect в системі, з коробки його нема).
Або взагалі красиво підійти до справи й відправити POST запит. В цьому запиті вказати Web Shell
. А в query параметрі вказати поряд з
page=php://input ще й
cmd=whoami. В такому сценарії, PHP робить
require('php://input'), що своєю чергою імпортує код з тіла POST запиту
(так php://input працює) й інтерпретує його. А в тілі запиту ми тримаємо команду
system(), яка викликає ту команду, яку ми вказали через параметр
cmd. Що також призводить до можливості виконувати команди.
Чи вразливі інші мови?Я на прикладі PHP розглядав це, але чи вразливі інші мови? Звісно! Всі мови програмування в тому чи іншому виді імпортують файли. У них різні для цього механізми, різні функції та й інше, але це можливо. І якщо ваш код на .NET, Java чи Node.js робить імпорт файлу, шлях до якого може контролюватись ззовні — ви в зоні ризику. А якщо ще й ті функції імпорту, які підтримують можливість робити імпорт через другі протоколи — вектор атаки збільшується.
Та чи можна захиститись?Так, можна. Я б дав декілька порад на цю тему.
По перше, зробіть нормальний регулярний вираз, який виступає в ролі фільтра для вашого параметра. Якщо ви не можете обійтись без того, щоб не імпортувати шляхи які контролюються ззовні, то максимально затягніть пояс для можливих варіантів.
По друге, якщо хакер вже і пройде через перший фільтр, то не використовуйте для імпорту функції, які дозволяють імпортувати через інші протоколи, тільки локальні файли. Це потенційно знизить надану шкоду.
А взагалі, намагайтесь просто ніколи не робити таких імпортів. В такому випадку вектор звузиться
912 views08:34
W
