По долгу службы я, периодически, сталкиваюсь с разного рода должностным несоответствием.
Например с тех.поддержкой которая не знает, как работает поддерживаемый продукт.
Но с таким знакомы все и никого этим не удивишь. Расскажу о совершенно вопиющем случае.
Оговорюсь сразу: Я знаю о правилах хорошего тона в интернете и о том что нужно сообщать владельцам ресурсов или хостингов о найденных уязвимостях. В данном случае я этого делать НЕ стал, ввиду отсутствия уязвимости и наличия непристойной глупости.
Одним прекрасным утром появилась у меня необходимость проверить, как будет работать сайт одной фирмы на другой площадке, в виду возможного переезда.
Выяснилось, что сайт хостится компанией, которая его и раскручивает. Для управления служит программа DBedit, найти которую на сайте компании оказалось уже проблемой. Успешно справившись я приступил к подключению CMS к сайту. У меня был подробный мануал, созданный для людей совершенно разной компьютерной грамотности. При чтении сего манускрипта у меня и закрались первые сомнения в адекватности компании хостера.
Дело в том, что сайт хранится на сервере в базе данных InterBase. Я с ней знаком не по наслышке и точно знаю, что при установке создаётся стандартная пара логина-пароля SYSDBA – masterkey, и её необходимо ОБЯЗАТЕЛЬНО сменить на любую другую. Клиенту Логин-Пароль выдаётся в их первозданном виде. Так вот в мануале о необходимости смены пароля нет не слова. Напомню, что мануал рассчитан на дизайнера или контент менеджера, который о стандартных паролях понятия не имеет. Забегая вперёд отмечу, что через интерфейс DBedit его сменить нельзя и общение в поддержку тоже ничего не дало. Пароль не изменяем!
«Ну и ладно» — скажите Вы.» Наверняка есть ещё один уровень безопасности ограничивающий доступ к контенту.»
Можно я Вас расстрою? – Его нет. Честно. Ну правда. Вот доказательство:
Можете спростить: « А как на счёт параметров соединения? Их то взломщик не знает.»
А вот и знает. Достаточно: купить их хостинг/спросить у друга уже имеющего у них аккаунт — и вы будете знать типовые параметры. Они не сложные:
И всё. То есть совсем всё. Для подавляющего большинства их клиентов эти параметры одинаковы.
Можете заходить в CMS, рулить контентом, делать что вздумается. Не забывая сохранять изменения.
Вот тут меня ждал ещё сюрприз – никакие изменения внесённые через CMS на сайте не отображались. Но у меня был текстовик с мануалом…
Нужно зайти на специальный сайт, и ввести там другие(sic!) логин-пароль чтобы изменения применились.
«Ну слава богам! Вот оно препятствие для кулхацкеров!» — подумал я и ошибся.
Заходим на спец.сайт, вида:
У Вас спрашивают аутентификацию.
Где Логин — %ваш_домен%, а пароль – первые 4 символа от %ваш_домен%.
Ну не чудо ли? Это справедливо для большинства доменов, которые хостятся у этой компании. Изменить эти данные тоже не представляется возможным.
На сайте просматриваете все сделанные изменения. После чего переходите по ссылке
и всё. Все сделанные Вами изменения выносятся на продакшн.
С помощью PING-a узнал я IP сервера, на котором лежал наш сайт.
На ресурсе 2IP.RU узнал все домены находящиеся на этом IP.
И прошёлся по списку. Стандартные пароли подошли почти ко всем из 84-х сайтов на этом адресе.
Проверил соседние ip — там такая же ситуация.
Проверял и подключение к CMS и подходит ли пароль к предпросмотру-админке на сайте.
По самым скромным подсчётам, пароли одинаковые минимум у ста сайтов.
Профессионализму ребят можно позавидовать.
Название конторы я не буду называть по трём причинам:
Спасибо за внимание.
Например с тех.поддержкой которая не знает, как работает поддерживаемый продукт.
Но с таким знакомы все и никого этим не удивишь. Расскажу о совершенно вопиющем случае.
Как я ломал сайты
Оговорюсь сразу: Я знаю о правилах хорошего тона в интернете и о том что нужно сообщать владельцам ресурсов или хостингов о найденных уязвимостях. В данном случае я этого делать НЕ стал, ввиду отсутствия уязвимости и наличия непристойной глупости.
Одним прекрасным утром появилась у меня необходимость проверить, как будет работать сайт одной фирмы на другой площадке, в виду возможного переезда.
Выяснилось, что сайт хостится компанией, которая его и раскручивает. Для управления служит программа DBedit, найти которую на сайте компании оказалось уже проблемой. Успешно справившись я приступил к подключению CMS к сайту. У меня был подробный мануал, созданный для людей совершенно разной компьютерной грамотности. При чтении сего манускрипта у меня и закрались первые сомнения в адекватности компании хостера.
Дело в том, что сайт хранится на сервере в базе данных InterBase. Я с ней знаком не по наслышке и точно знаю, что при установке создаётся стандартная пара логина-пароля SYSDBA – masterkey, и её необходимо ОБЯЗАТЕЛЬНО сменить на любую другую. Клиенту Логин-Пароль выдаётся в их первозданном виде. Так вот в мануале о необходимости смены пароля нет не слова. Напомню, что мануал рассчитан на дизайнера или контент менеджера, который о стандартных паролях понятия не имеет. Забегая вперёд отмечу, что через интерфейс DBedit его сменить нельзя и общение в поддержку тоже ничего не дало. Пароль не изменяем!
«Ну и ладно» — скажите Вы.» Наверняка есть ещё один уровень безопасности ограничивающий доступ к контенту.»
Можно я Вас расстрою? – Его нет. Честно. Ну правда. Вот доказательство:
Можете спростить: « А как на счёт параметров соединения? Их то взломщик не знает.»
А вот и знает. Достаточно: купить их хостинг/спросить у друга уже имеющего у них аккаунт — и вы будете знать типовые параметры. Они не сложные:
%имя_вашего_сайта_без_доменного_суффикса%.адрес_хостинга.ru: %имя_вашего_сайта_без_доменного_суффикса%И всё. То есть совсем всё. Для подавляющего большинства их клиентов эти параметры одинаковы.
Можете заходить в CMS, рулить контентом, делать что вздумается. Не забывая сохранять изменения.
Не всё так просто! А, нет. Просто.
Вот тут меня ждал ещё сюрприз – никакие изменения внесённые через CMS на сайте не отображались. Но у меня был текстовик с мануалом…
Нужно зайти на специальный сайт, и ввести там другие(sic!) логин-пароль чтобы изменения применились.
«Ну слава богам! Вот оно препятствие для кулхацкеров!» — подумал я и ошибся.
Заходим на спец.сайт, вида:
%ваш_домен%.%домен_хостера%.ruУ Вас спрашивают аутентификацию.
Где Логин — %ваш_домен%, а пароль – первые 4 символа от %ваш_домен%.
Ну не чудо ли? Это справедливо для большинства доменов, которые хостятся у этой компании. Изменить эти данные тоже не представляется возможным.
На сайте просматриваете все сделанные изменения. После чего переходите по ссылке
%ваш_домен%.%домен_хостера%.ru/genstart и всё. Все сделанные Вами изменения выносятся на продакшн.
Перепроверка
С помощью PING-a узнал я IP сервера, на котором лежал наш сайт.
На ресурсе 2IP.RU узнал все домены находящиеся на этом IP.
И прошёлся по списку. Стандартные пароли подошли почти ко всем из 84-х сайтов на этом адресе.
Проверил соседние ip — там такая же ситуация.
Проверял и подключение к CMS и подходит ли пароль к предпросмотру-админке на сайте.
Послесловие
По самым скромным подсчётам, пароли одинаковые минимум у ста сайтов.
Профессионализму ребят можно позавидовать.
Название конторы я не буду называть по трём причинам:
- Фирмы держащие свои сайты у них, вряд ли обрадуются дефейсу.
- Нет желания учить оболтусов сайты на скорую руку ломать.
- По подсказкам в тексте очень просто самим найти злополучную контору.
Спасибо за внимание.
