Нередко можно услышать, как на том или ином сайте в Интернет похозяйничали хакеры, изменив контент нужным им образом. И тогда среди широкой интернет-публики, не исключая и владельцев сайтов, обычно наблюдается скорее эмоциональная реакция, нежели трезвый анализ с производством необходимых выводов и адекватных действий.
С подобным случаем взлома недавно столкнулся и я. Но в отличие от прочих, я тщательно расследовал инцидент и собрал необходимую информацию. Узнав о ней и проанализировав собственную ситуацию на веб-сервере, каждый владелец теперь может сделать обоснованный вывод, повысив свою безопасность пребывания в Интернет.
Наиболее популярным (хотя бы в пределах Рунета) инструментом администрирования shared-вебсервера является cPanel, текущий релиз которой есть 10.8.2-RELEASE-119. По крайней мере, на некоторых хостерах при создании пользовательского эккаунта к нему сразу (т.е. по умолчанию) присоединяется Frontpage расширение. Видимым в папках домашней директории сайта (т.е. обычно в public_html) признаком этого является наличие структуры каталогов, начинающихся на _vti_, а в каталоге _vti_pvt лежит файл service.pwd, где в хешированном виде находится пароль на эккаунт пользователя. Защитой (как показала практика, весьма эфемерной) от доступа по http к нему по мысли разработчиков служит запись в файле .htaccess такого содержания:
# -FrontPage-
IndexIgnore .htaccess */.??* *~ *# */HEADER* */README* */_vti*
<Limit GET POST>
order deny,allow
deny from all
allow from all
</Limit>
<Limit PUT DELETE>
order deny,allow
deny from all
</Limit>
AuthName <site.url>
AuthUserFile /home/<user_account>/public_html/_vti_pvt/service.pwd
AuthGroupFile /home/<user_account>/public_html/_vti_pvt/service.grp
=========
где <user_account> - это эккаунт пользователя, или по иному - его логин.
Ясно: получив доступ к файлу service.pwd, где пусть и в хешированном виде* находится пароль на эккаунт, хакер получает все средства, чтобы делать с пользовательским сайтом абсолютно всё, что ему желательно!
* примечание: ведь всем должно быть ясно, что в современных условиях вовсе не нужны компьютеры cray или иные из арсенала ФБР, чтобы хакер комфортно, у себя на компьютере, весьма быстро нашел первый подходящий пароль, дающий такой же хэш; это означает, что хакер получает ПОЛНЫЙ доступ к эккаунту этого пользователя...
Именно так и происходят характерные взломы там, где используется эта фишка, так было у меня: файл .htaccess оказался после взлома обнулённым (и/или переименованным), а хакер похозяйничал, как хотел, ибо получил доступ такого же уровня, как владелец эккаунта!
Тут присутствует известный "психологический" момент: если хостер не запретил использовать Frontpage, и особенно если эккаунт дефолтно создаётся с таким расширением (как было в моём случае), 99% юзеров даже не задумаются об их уязвимости (не посмотрят в эти папки, не проанализируют уязвимость, как я показал выше). Следствие чего является МАССОВАЯ уязвимость самой большой группы вебсайтов, располагающихся на "дешевых" хостингах (точнее - везде, где можно подключить эту фишку ТАКИМ СПОСОБОМ, и особенно если это делают предустановленные скрипты автоматически, и это проблема хостера)...
Не верю я в то, будто бы подобная фишка с Frontpage является недосмотром (тех же поставщиков cPanel). Напротив, при формальной "безобидности" и юридическом прикрытии "законности" использования подобных расширений оно является ПО СУТИ замаскированной backdoor ко многим пользовательским интернет-эккаунтам (следовательно, с их сайтами можно делать что угодно).
Делайте выводы, господа! Мы живём в эпоху информационных войн...
С уважением, администратор интернет-сервиса "Репетиторство XXI века" www.rxxi.info,
Андрей Микитенко
Примечание. Эта статья постоянно находится здесь: http://www.rxxi.info/pdf/security/one_of_s...brittleness.pdf

ПОСЛЕСЛОВИЕ, ДОБАВЛЕННОЕ ПОСЛЕ ОКОНЧАНИЯ ПРЕНИЙ В ТЕМЕ
Результатом публикации этой темы и обсуждения её лично для меня явилось подтверждение тех моих давних наблюдений и наступившая уверенность в моих давних предположениях, что касаются положения дел в шаред-сегменте хостинг услуг.
Выводы в главном: всё возрастающие на глазах возможности, предоставляемые техникой и технологией (быстрый рост мощностей серверов с одновременным падением цен, а также совершенствование средств обеспечения выдачи и обработки веб-контента) ныне быстро начинают вступать в противоречие с моделями шаред-хостинга и политикой, однажды выбранной кем-то относительно способов виртуализации хостов. Следствием этого является предпосылки к ненадёжности обеспечения безопасности виртуальных хостов, следовательно падает безопасность сайтов клиентов, снижающаяся всё более и более в условиях крайне агрессивной современной "среды обитания", Интернета.
(Многие люди, причастные к этому сектору, до сих пор не пересмотрели расхожие мнения относительно условий и средств обеспечения безопасности, выработавшиеся в *никс среде ещё в давние времена и приемлемые лишь в условиях траст-сетей, т.е. скорее корпоративного интранета, нежели Интернета! Если же люди, причастные к хостингу, заявляют: де не следует требовать от хостинга в Интернет безопасности, - тем самым, они показывают свою профессиональную несостоятельность и отсутствие способности к здравым суждениям...)
Конечным следствием такого ненормального положения дел является уже случившаяся и быстро нарастающая маргинализация этого сегмента рынка.

Между тем оригинальные решения разработчиков по виртуализации хостов в рамках веб-сервера Апачи обеспечивали вполне приемлемые технические условия для разумной политики виртуализации хостов (необходимой для обеспечения возможности хостинга по разумно низкой цене) и одновременного обеспечения должной безопасности. Лишь пресловутый человеческий фактор является виной сложившемуся ныне ненормальному положению вещей в этом сегменте услуг. Техника и технология, наоборт, ныне как никогда обеспечила бы высочайший уровень услуг при низких ценах.
Нужно сказать, что сам по себе способ разделения ресурсов (шаред-хостинг) не является чем-то порочным или предрасполагающим к резкому понижению безопасности хостов. Но это верно лишь при условии, когда соблюдены известные технические приёмы и наложены разумные ограничения, вызванные скорее не технологией, а самим фактом наличия своеобразной "коммуналки" в пределах одного физического сервера. Если же разумности в этой политике не наблюдается*, тогда неудивительно наличие решений, препятствующих соблюдению обозначенной разумности в политике вирутализации хостов и управления ими. Что и ведёт к резкому снижению безопасности хостинга.
* Примечание: скажем, как наиболее типичное явление - жадность при "делении" физического сервера на как можно большее число виртуальных хостов, что непременно будет сопровождаться желанием выжать максимальную производительность, что в свою очередь приводит разработчиков автоматических "администраторов" - без них в реселлерстве не обойтись! - к желанию применить "решения", резко снижающие порог безопасности.
---
Вот это и есть причина наступающей здесь маргинализации. В таких условиях разумно требовательные клиенты несомненно будут уходить из этого сегмента в сегмент, где не наблюдается такого положения дел (ныне это VPS/VDS рынок услуг).
К счастью, этот и прочие новейшие технологические разработки по виртуализации более высокого уровня (выше уровня вебсервера) уже доступны по цене и ассортименту услуг, это будет нарастать впредь и развиваться (особенно при условии "перетекания" к ним массы клиентов с шареда).
Между тем, по сугубо техническим факторам шаред вполне подходит очень многим клиентам и удовлетворяет требования всех интернет-проектов, которые:
а) не требуют слишком больших ресурсозатрат от сервера (это тривиально);
б) применённые решения не требуют чего-то большего, чем использование всех богатейших возможностей, заложенных в сетевых языках программирования. Т.е. не требуют запуска каких-либо сервисов, кроме ограниченного спектра предопределённых, навроде крона, или ныне многим необходимого WMSigner'а, проверенного и едва ли могущего создать проблемы. Прочие должны быть запрещены директивно!
(След-но, это автоматически означает запрет на запуск и любых как-либо загруженных хакерами инструментов взлома.) Если пользовательские проекты не требуют запуска специально написанных для проекта каких-либо *никс-приложений, они не могут представлять угрозы при размещении на шареде, но лишь при соблюдении там должных приёмов безопасности.
Любой юзесркий эккаунт на шареде должен быть "заперт" в пределах своей homedir, юзер ни какими доступными техническими средствами не имеет право и не должен иметь возможность читать любые прочие данные и исследовать конфигурацию хостов "соседей". Из скриптов ДОЛЖНО БЫТЬ разрешено исполнять лишь те команды и запускать лишь такие приложения, что предопределены известными правилами, которые проверены годами (на предмет того, что такие ресурсы не могут представлять угроз).
Несоблюдание же всего этого вызвало бы явное снижение безопасности - не только для своего виртуального хоста, но и для вебсервера в целом, след-но, угрожало бы безопасности всех "соседей".

Итак, не недостатки техники или технологий есть причина этих печальных явлений, а именно известные свойства человека как такового, причастного к разработке известных частных решений для данного сегманта услуг.

ПРАКТИЧЕСКИЙ ВЫВОД.
Не следует забывать, что любой "переезд", даже виртуальный, требует от владельцев ресурса усилий и затрат времени, а часто и немалых средств или риска потери клиентов из-за перебоев работы сайта. Поэтому ныне как никогда уже при начале работ над проектом требуется семь раз подумать, прежде чем отмерить и взять шаред-хостинг, даже если проект не нуждается в нестандартных технических решениях или даже "навырост" не потребовал бы высоких ресурсозатрат...

Ну на нормально настроенном хостинге к этому файлу злоумышленник сможет получить доступ только через дыры в скриптах этого же пользователя, что вобщем-то совершенно естественно.
Но тут, конечно, вариант более опасный нежели привычное раскрытие пароля от mysql-базы...

РуВеб совершенно прав!
Способ рискованный ну и опасный соответственно!

И заголовок темы исправили бы чтоли... "Взлом shared-вебсервера" и "взлом аккаунта c FrontPage на shared-вебсервере" это 2 большие разницы, не находите?
А "фишка" эта наверняка и не является недосмотром разработчиков панелей управления, а видимо является штатным режимом функционирования FrontPage. Который при адекватных настройках безопасности веб-сервера, и отсутствии дыр в скриптах пользователя опасности не представляет, как мне кажется.

Зачем что либо придумывать если можно и так пошаритсья по всем аккаунтам получив лиш данные из /etc/passwd и зная какая архитектруа папок на данном сервере в /home/

Если на хоме стоят права 711 а напапках юзеров 711 это не значит что по этим папкас нельзя шариться!

А если учесть что cpanel пашет везде стандартно, то на любом cpanel хостинге можно из 200-300 аккантов на сервере найти от 5 до 20 акканутов где можно найти папку, в которую можно записать что-либо, а дальше уже дело техники

Это зависит откуда взламывать - имея досутп на самом сервере или из вне.
Если снаружи - тогда проблема в слабых паролях (атака по словарю).
Если изнутри - тогда проблема в правах. Нужно использовать 750/640 права.

Не преувеличивайте. Не на любом, а только на криво настроенном.

Но согласен, что это проблема скорее не Cpanel, а админов малограмотных или малоопытных.

eSupport.org.ua,
Ну внутри если апач пашет от nobody xx0 права ставить проблемно!
А доступ внутрь получить можно легально купив хостинг!

И что же вы будете искать?

Права user:nobody 750 без проблем ставятся на public_html и юзером чужим вы внутрь этой папки уже не пролезете. А апачем через php не даст пролезть safe_mode или open_basedir. Неужто вы об этом не знали?

Мне хватит найти папку, на которой юзер поставит 777 или хватит найти файл config.php с паролями от базы и стереть её или застопорить нормальную работу вашего MySQL сервер!



Не ужели в не знаете что не все клиенты приемлют safe_mode
Не ужели вы не знаете что многие юзара сами самостоятельно ставят на public_html права выit чем 750 только потому что во многих скриптах к которым есть документация рекомендуют ставитьправа как можно выше без учета безопасности в целом?
Не ужели вы не знаете что админы всех хостинг компаний не следять за всеми аккаунтами юзеров кто какие права ставит!

В итоге из 100-300 акканутов на одном сервере находтися много клиентов умников, которые позволяют себя взломать другим клиентам этого же хостинга! И это проблема с одной стороны клиентов, с другой то что админы не следят за этим автоматически снимая с важных папок высоких прав!!!

На нормально настроенном хостинге, вы до этой папки добраться не сможете по уже описанным мной причинам.

И что? Это их проблемы. Это не повод подвергать опасности аккаунты других клиентов. Не устраивает safe_mode/open_basedir - идите на хостинг, где php работает от юзера. Нет? Тогда забудте слово "безопасность".
Кстати, на наших серверах мы используем модифицированный вариант safe_mode, и никаких проблем с доступом из своих сктриптов к своим файлам у клиентов обычно не возникает. Единственное серьезное неудобство - невозможность запуска внешних программ (кроме WMSigner ;)
Это их проблемы. Они могут хоть пароль от аккаунта у себя на главной странице написать. Мы говорим о безопасности системы и дефолтовых настроек аккаунта, а не о том на какие глупости способен клиент.
А зачем? Если кто-то сам вырыл себе яму и понаделал дырок в безопасности _своего_ аккаунта - он сам себе злобный Буратина.

Повторяю в 4й раз. Это проблема "умников, которые позволяют себя взломать" и только их.

На счет safe_mode - это лечение перхоти гильотиной.
А open_basedir обойти не так уж и сложно

Как вам сказать. Вообще-то, для лечения именно этой "перхоти" safe_mode и был создан. Вполне приемлимое решение, как показала практика. Не намного лучше/хуже того же open_basedir.
Естественно, речь идет не об open_basedir самом по себе, а о некотором комплексном решении на его основе.

Все упирается в скрипты с уязвимостями и/или слабыми паролями. Само по себе Frontpage расширение уязвимости не дает.

ClayRabbit, заведите мне у вас полноценный доступ на несколько дней, если вы правы, то я не смогу на хостобзоре выложить никаких чужих данных других ваших клиентов, если нет, то сами и будите виноваты

Доступ можно в ПМ послать!

Я не исключаю, что у вас все супер настроенно, но вы это не 100% других хостинг компаний юзающих cpanel.

Да и желательно чтобы на сервере было не меньше 100-200 акканутов (и также желательно чтобы они были не на голых html страницах)

Неужели трудно сообразить, что когда в домашней папке сайта находится пароль, пусть и хешированный, это огромная дыра в безопасности?!
Две огроменные разницы, когда взломщику нужно шарить где-то в /etc/passwd (куда еще нужно добраться!), или в домашней папке сайта...

Это не дыра, а лишь потенциальная уязвимость. Если в ваших CGI-скриптах нет дыр (или если вы вообще не пользуетесь CGI) она вам ровным счетом ничем не грозит.
(А до /etc/passwd добраться легко, вот только пароли там не хранятся.)

Как вы прочтете пароль из config.php, если ещё не взломали сервер? И что вам даст знание пароля на MySQL? В норме он отличается от пароля на эккаунт.
Что вам даст нахождение папки с правами 777, если это не папка, где лежат и исполняются скрипты? (Да и как вы найдёте такую папку, ЕЩЁ не зломав эккаунт юзера?)

Да, CGI я не использую давным-давно, ибо есть PHP. Но папку для CGI все вирт. хостинги создают автоматически... (и к том уже папку пустую... в принципе это может как-то способствовать хитроумным комбинациям хакеров... или я не прав?)
Однако как вы сможете, являясь просто посетителем сайта (но с намерением взлома , добраться по http до папок сервера выше юзерского эккаунат? Поделитесь пожалуйста опытом (можно приватом на странице контакт у меня на сайте
P.S. приверен /etc/passwd разумеетя лишь как пример, он давно не актуален для взлома :^)

А нет. Я гоню. На нем же права 644, т.ч. прочитать его можно и php-скриптом под mod_php...
Если без safe_mode и open_basedir - то точно также - через относительный путь. Никакой принципиальной разницы нет.
Но мы с Drug'ом уже немного отходим от темы. Нас больше беспокоят способы добычи чужих данных, в случае когда злоумышленник имеет аккаунт на сервере.