Нові уразливості в XAMPP

19:32 25.07.2009

20.06.2009

У червні, 11.06.2009, а також додатково сьогодні, я знайшов Information Leakage, Cross-Site Request Forgery та SQL Injection уразливості в XAMPP. Про що найближчим часом сповіщу розробникам.

Раніше я вже писав про уразливості в XAMPP.

Детальна інформація про уразливості з’явиться пізніше. Спочатку повідомлю розробникам системи.

25.07.2009

Information Leakage:

http://site/xampp/phpinfo.php

При доступі в адмінку (через Insufficient Authorization уразливості) можна отримати багато інформації про систему.

CSRF:

http://site/xampp/cds.php

Можна видаляти та додавати дані в тестовій таблиці (як через CSRF, так і через Insufficient Authorization уразливості). А також проводити SQL Injection через CSRF атаки.

SQL Injection:

http://site/xampp/cds.php?action=del&id=-1%20or%201=1

http://site/xampp/cds.php?interpret=1&titel=1&jahr=1),(version(),1,1

http://site/xampp/cds.php?interpret=1&titel=’,1,1),(version(),1,1)/* (mq off)

http://site/xampp/cds.php?titel=1&interpret=’,1),(version(),1,1)/* (mq off)

Атака можлива при доступі в адмінку (через Insufficient Authorization), або через CSRF.

Уразливі XAMPP 1.6.8 та попередні версії. Та потенційно наступні версії (включно з останньою версією XAMPP 1.7.1).


4 відповідей на “Нові уразливості в XAMPP”

  1. poma каже:

    >> Можна видаляти та додавати дані в тестовій таблиці
    >> Атака можлива при доступі в адмінку
    вауу! як круто :D цікаво нашо скуль в адмінці? там ціль залити шелл і получити рута )

  2. MustLive каже:

    вауу! як круто :D

    poma, CSRF атака можлива не тільки при власному доступі в адмінку, а й при атаці на адміна (залогіненого в адмінку). І окрім видаляння та додавання даних в тестовій таблиці, також можна проводити SQL Injection атаки через CSRF.

    Що можна використати для залиття того ж шела (якщо mq вимкнені). Для цього потрібно буде знати шлях не сервері, який можна отримати через Full path disclosure уразливості в XAMPP, про що я писав, чи інші FPD на сайті. Про CSRF я згадав, щоб нагадати і розробникам XAMPP, і усім веб девелоперам, що й такі дірки існують, і потрібно їх також виправляти.

    цікаво нашо скуль в адмінці?

    В XAMPP адмінка дуже слабка. Отримавши до неї доступ, ти з неї особливо нічого зробити не зможеш, окрім отримання деякої інформації (через вищезгаданий phpinfo.php та інші сторінки адмінки).

    Тому для атаки на сайт потрібно використовувати дірки в самому XAMPP, яких я знайшов чимало і про які розповідаю. Зокрема через SQL Injection уразливість. Причому через SQLi можна як шел залити (при відповідних налаштуваннях на сервері), так і можна безпосередньо дані з БД прочитати ;-) .

  3. poma каже:

    >> Для цього потрібно буде знати шлях не сервері
    не тільки це. ще потрібно знати папки, доступні для запису, з прм. 0777.
    ти про такі не сказав, доречі.

    >> а й при атаці на адміна (залогіненого в адмінку)
    а тут вже буде більше СоціальноїІнженерії, шоб впарити адміну сторонній лінк.

  4. MustLive каже:

    не тільки це.

    Умов там чимало для запису файлів через SQLі й про всі них я сказав у фразі “при відповідних налаштуваннях на сервері”. Так як я ж не роблю лікбеза по даним атакам, лише зазначаю, що при наявності SQLi така атака можлива (за відповідних умов), тому SQLi в адмінці XAMPP можна для цього використати (а також для інших атак). Так що SQLi в адмінках також небезпечні (особливо в “слабеньких” адмінках) й можуть бути використані для атаки, тому їх також потрібно виправляти ;-) .

    з прм. 0777.

    0666 цілком вистачить, як мінімум потрібні права на запис. Які папки будуть доступні для запису, це вже справа нападника, щоб їх виявити (а так як на різних сайтах вони можуть відрізнятися, тому потрібно перевіряти всі відомі папки і знаходити потрібну на кожному сервері з XAMPP). Наприклад, на одному сервері з XAMPP, який я похакав, щоб повідомити адміна про проблеми з безпекою, я записав шел в корінь XAMPP-вської папки. Але серед тих серверів з XAMPP, в адмінку яких я заходив, виявлялося, що в них включені mq (окрім одного вищезгаданого). Це може бути стандартним налаштуванням XAMPP, тому залиття шела в такому випадку неможливе (якщо налаштування не були змінені, що треба на кожному сайті перевіряти), зате можливі інші атаки через SQLi уразливості.

    а тут вже буде більше СоціальноїІнженерії, шоб впарити адміну сторонній лінк.

    Ясна річ, що для CSRF потрібна соціальна інженерія. Це те, що само собою розуміється, що для CSRF, як і для reflected XSS, потрібна соціальна інженерія. І це вже задача нападника, заманити жертву у пастку. І насправді особливих проблем тут намає, тому провести CSRF атаку цілком реально (при достатньому професіоналізмі), в тому числі існують приховані методи атаки.

    Тому дані уразливості також потрібно виправляти. А на CSRF і XSS люблять забивати (і не виправляти), причому на CSRF ще більше ніж на XSS, в зв’язку з наявністю складової соціальної інженерії в атаці. І зовсім даремно, бо ці атаки можуть бути достатньо небезпечними.

Leave a Reply

You must be logged in to post a comment.