Уязвимость ISPManager

Discussion in 'Безопасность и Анонимность' started by Raistlin, 9 Sep 2010.

  1. Raistlin

    Raistlin New Member

    Joined:
    12 Apr 2010
    Messages:
    9
    Likes Received:
    0
    Reputations:
    0
    http://forum.searchengines.ru/showthread.php?t=538868&page=11 - здесь оригинал.

    Думаю, кому-то будет интересно.

    Теперь размеренно расказываю что такое.
    Ну, собственно, с чем это связано...

    Связано это с тем, что ISPSystem не позаботились о безопасной пересылке данных для авторизации через API, и сама по себе панелька работает от имени пользователя root. На мой взгляд изначально писать панельку таким образом было не совсем верно, но теперь чего уж сделать. Панелька для выполнения каких-то действий, а так же при авторизации (в том числе и через API) делает вызов к апачу. Вызов вида http://hostname/ipsmgr?authinfo=root:password
    Ну то, что такой урл вызывается из-под апача дает злоумышленнику возможность получить рутовый пароль при парсинге server-status. Таким же образом можно при желании отловить пароль любого пользователя.

    Варианты защиты от этой баги:

    1. Запретить сервер-статус совсем.
    2. Сделать на него алиас не /server-status, а, скажем, /serv-stat-info
    3. Выключить расширенный статус апача.

    Дело в том, что даже если сервер-статус скрыт для удаленного пользователя, многие хосты дают возможность использования SSH и/или perl/cgi (system в php.ini не у всех закрыты). Собственно, можно по крону скриптом с того же шелла вгетом брать сервер-статус и парсить его.

    Что должно быть сделано ISPSystem для закрытия баги:
    1. Передача пароля в захешированном виде.
    2. Вообще весьма желательно, чтобы процессы использовали внутренние протоколы обмена данными либо общались через сокеты линукс. Например, когда биллинг и манагер стоят на одном сервере.
    3. API не должно вообще обрабатываться через апач. Для этого должен быть занят отдельный порт, через который бы шли данные между биллинг-системами и панелью.
    4. Панель не должна иметь привилегии пользователя root постоянно, а должна выполняться с правами локального пользователя. Права root должны ей приобретаться через специальный вызов через какой-либо враппер.

    За сим все.

    Теперь если вы нашли человека, который не закрыл сервер-статус с мира вы можете парсить его каким-либо софтом. Если вы купили хостинг и он предоставляет вам SSH с панелью ISPManager, проверьте, работают ли wget или curl. Если да, плюс у вас есть крон... Можно сделать следующим образом.

    wget http://localhost/server-status (если не выдаст 404, значит надо посмотреть, что он нам отдал - расширенный ли статус отдает апач).

    Ну и сам скрипт:
    wget http://localhost/server-status -O /myhomedir/server-status
    cat /myhomedir/server-status | grep root >> /myhomedir/parsed-status

    Ну и останется только добавить это в крон (раз в минуту), а дальше просто ждать... КОгда зайдет админ через биллинг, либо биллинг начнет выполнять какие-либо действия, эти две строки кода запишут в файл parsed-status строку, в которой будет содержаться рутовый пароль к этому серверу.

    Общие идеи дал, дальше - смотрите сами, может где и ошибся.
     
    #1 Raistlin, 9 Sep 2010
    Last edited: 9 Sep 2010
  2. Greed

    Greed New Member

    Joined:
    9 Dec 2010
    Messages:
    1
    Likes Received:
    0
    Reputations:
    0
    Собственно, ссылка уже не актуальна

    Ну во первых, authinfo передается только когда вы связываете несколько продуктов ISPsystem в одну систему (Например подключаете панель к биллингу). При работе через браузер все передается через post.

    Самое простое - это не включать расширенный server-status. Не знаю, что у вас за дистрибутив, но на Denian по умолчанию он включен без Extended, на Centos и FreeBSD - вообще не включен.

    По вашей же логике, что мешает злоумышленнику использовать захешированный пароль, если панель будет его принимать?
     
Loading...