Взломали сайт

[Krasniy001]

Взломали сайт, снесли базу, поставили дефаултную, путь к картинкам и стилям вел к /s2c/ и еще половину на localhost

Может такое быть или из за чего тогда БД поставилась дефолтная?

[VST]

1. Версия?
2. Хранение паролей в ФТП клиенте?
3. Вкрапления в коде?
4. Другие сайты сайты на хосте?
5. URL в поддержку.

[Krasniy001]

1. Версия?
2. Хранение паролей в ФТП клиенте?
3. Вкрапления в коде?
4. Другие сайты сайты на хосте?
5. URL в поддержку.

1. 3.6 Англ
2. Filezilla, другие сайты не пострадали
3. Не искал
4. Не взломали

[VST]

1. 3.6 Англ

Enterprise или Free? Сторонние разработки, дополнения?

3. Не искал

Внимательно проверьте.

[nemo]

А вы проделали рекомендуемое в нашей Базе знаний http://www.viarts.ru/osnovi_bezopasn...-magazina.html сразу после установки скрипта? Или оставили непериименованной папку admin + не удалили install.php?

[Krasniy001]

А вы проделали рекомендуемое в нашей Базе знаний http://www.viarts.ru/osnovi_bezopasn...-magazina.html сразу после установки скрипта? Или оставили непериименованной папку admin + не удалили install.php?

файла install.php стер, папку admin не переименовывал, htaccess не ставил.

---------- Добавлено в 20:55 ---------- Предыдущее сообщение было написано в 20:54 ----------

Enterprise или Free? Сторонние разработки, дополнения?

Enterprise, без сторонних разработок и дополнений.

Внимательно проверьте.

а как проверить если я уже вернул старую базу из бекапа?

[gromov]

искренне, от всей души поздравляю с тем, что был бекап
и спасибо, что отписались на форуме. Первые звоночки, блин.

[khoser]

и спасибо, что отписались на форуме. Первые звоночки, блин.

не первые, нас ломали в течении месяца по выходным, причем последний раз залезли на сам хост и снесли оттуда все что было, по времени примерно ночью. с хостером был крупный скандал, сейчас на данном хостинге остался один сайт все остальное перенесли, все рекомендуемые мероприятия проделаны были, ориентировочный вердикт sql-инъекция, резервные копии делаем практически ежедневно, но все равно не приятно

Сейчас позакрывали вообще все что можно, совет - на хосте отметте доступ к папке bd 444

[Ches]

Ещё раз внимательно посмотрели Security Bug Track по v.3.xx за последние 3 года.
По 3.6 нет проблем. Версии почти год при наличии уязвимости сайты сыпались бы десятками.
Доп. рекомендации ТС
- тщательно провериться на вирусы
- не хранить пароли в браузере
- фаервол
По v. 4.05

Dork:
# N/A
 
Application Info:
# ViArt SHOP
# version last 4.0.5
 
Vulnerability Info:
# Type: multiple SQL injections, multiple XSS, multiple iFrame injections,
multiple link injections , redirector abuse.
 
Time Table:
# 10/11/2010 - Vendor notified.
# 18/11/2010 - Vendor released fix

Закрыто. Патч в файловом архиве.

[nemo]

Позволю себе ещё несколько мыслей вслух:
Из моей практики, в подавляющем большинстве случаев, результатом несанкционированного доступа является заражение компьютера пользователя (троянские программы) или уязвимость хостинга вообще. Целенаправленный взлом конкретного сайта через его уязвимость - крайне редкий случай. Для этого, во-первых, нужно хорошо знать на чём сделан сайт, т.е. движок должен быть достаточно известен и распространён. Во-вторых, если становится известна уязвимость у известного движка, взломы массово прокатываются "волной" по всем сайтам.
Теперь давайте логически посмотрим с учетом вышеизложенного на ваш частный случай. Viart Shop пока не является широко распространённым и известным скриптом. Следовательно, о его устройстве (код, структура, теоретически возможные уязвимости) знает достаточно ограниченный круг пользователей. Это значит, что если предположить теоретически, что кто-то, кто хотел взломать целенаправленно ваш сайт, должен был специально потратить очень много времени на изучение этого движка. Простому программисту это не нужно совсем, возможным конкурентам по бизнесу - не по зубам. Отсюда следующий вывод - когда конкретный сайт ломают целенаправленно, для этого привлекаются специалисты и это стоит денег. За бесплатно, просто так, незнакомый скрипт никто ломать не будет - сломают знакомый, который очень широко распространён. Не думаю,что ваш проект на столько известен и раскручен, чтобы кто-то оплатил работу по изучению движка, поиску уязвимостей и сам взлом.

Все последние подобные происшествия, известные лично мне, случились из-за банального заражения компьютеров. Автоматически пересылаемые данные для доступа, хранящиеся на компьютере (в браузере, фтп-клиенте и т.п.) отправлялись куда-то, откуда так же, в автоматическом режиме, происходил несанкционированный ftp-доступ с заменой файлов или внедрением постороннего кода. Я для интереса забивал этот код в поисковик и находил кучу сайтов содержащих такой же, при чём на разных движках, и на блогах и на новостных сайтах, и в интернет-магазинах и т.д. Однозначно было видно,что взлом был по одному сценарию,но не через уязвимости движков этих сайтов. Один случай был вообще неприятный - взлом произошёл из-за заражённого компьютера разработчика скрипта, которому были даны данные для ftp-доступа для поиска и устранения ошибки в скрипте.
Т.ч. личное мнение - поищите причину в своём компьютере или виноват хостер. Простой взлом "в лоб" практически исключен.

[VST]

По данному случаю был проведен тщательный анализ. На сайте использовалась пиратская версия скрипта. Вопрос о безопасности и зашите ИМ от взлома в данном случае дальнейших комментариев не требует и снимается сам собой.

[Eugene-n]

А вы проделали рекомендуемое в нашей Базе знаний http://www.viarts.ru/osnovi_bezopasn...-magazina.html сразу после установки скрипта? Или оставили непериименованной папку admin + не удалили install.php?

Кстати, директория db находится в открытом доступе, в базе знаний об этом ни слова.
Полазил по некоторым живым сайтам, директория db у некоторых открыта. Бери дамп и пользуйся на здоровье.
Хочешь пароли админов, хочешь пользователей.
Не видим листинг директории db, но знаем формат имени дампа, только перебрать. Скачиваем, пользуемся.

[Subbota]

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

[nemo]

Кстати, директория db находится в открытом доступе, в базе знаний об этом ни слова.
Полазил по некоторым живым сайтам, директория db у некоторых открыта. Бери дамп и пользуйся на здоровье.
Хочешь пароли админов, хочешь пользователей.
Не видим листинг директории db, но знаем формат имени дампа, только перебрать. Скачиваем, пользуемся.

Ну, у большинства интернет-магазинов с приличном кол-вом товаров нет вообще смысла пользоваться встроенным функционалом по созданию дампа наработанной БД. Дело в том, что когда кол-во товаров приближается к 1000 на большинстве недорогих хостингов создать дамп не получится, сработает ограничение. Лично я, при создании копий БД пользуюсь сторонним дампером () или PhpMyAdmin в панели хостинга. И в том и в другом случае дамп скачивается на компьютер, а не оставляется на хранение на хостинге в папке bd. Иначе зачем нужен дамп? Дамп для подстраховки, если что-то случится с сайтом. А если что-то случится с сайтом, то в 99% случаев это постигнет и папку bd. Тогда какой смысл хранить там резервный дамп? Личное мнение - папка bd нужна только для хранения установочного дампа. После установки её можно удалить. Даже не удаляя, если не хранить в ней все последующие дампы, от установочного дампа нет никакой опасности, т.к. в нём нет никаких паролей и, вообще, никакой ценной информации, кроме демо-товаров.

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

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

Да, такие файлы есть и именно они (и на других движках сайтов тоже) в первую очередь подвергаются заражению при взломе в автоматическом режиме.

[DimTai]

Встроенный дампер удобно использовать при отладке. А делать делать бэкапы действующего ИМ удобней на хосте или сторонним софтом.

[Eugene-n]

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

Понятно, что дамп магазина мало применим в реальной жизни. Но база знаний по безопасности написана для уровня "ламер" и кто-то вполне может забыть удалить директорию db, что впрочем многие и забывают.
Кстати еще одна проблема, существует раздел support.php, который никак не защищен и при том, что ссылки на него нет на сайте, а сайта нет в поисковиках, туда гурьбой лезут боты и кидают спам. Был бы смысл туда добавит каптчу.
Тоже самое кстати с форумом, но там можно выставить каптчу. Так что есть предложение в коробочном варианте для форума по-умолчанию включить каптчу.

[nemo]

По поводу модуля Помощи (техподдержки). Там, где такая проблема была замечена, в файл роботс прописывали запрет для индексации, включали капчу для незарегистрированных для первоначальной страницы отправки запроса и, в админке, через функцию "Короткие URL для страниц" переименовывали support.php на любое другое нетривиальное. После этого, боты ищущие на сайтах любые упоминания по ключу support, не беспокоили.

[Subbota]

Но база знаний по безопасности написана для уровня "ламер" и кто-то вполне может забыть удалить директорию db, что впрочем многие и забывают.

Eugene-n, все в Ваших руках пишите, выкладывайте, думаю администрация с удовольствием пополнит базу знаний Вашим "багажом" ) если он будет уместен и полезен.

[Eugene-n]

По поводу модуля Помощи (техподдержки). включали капчу для незарегистрированных для первоначальной страницы отправки запроса

Каптчи там вроде нету?

[nemo]

Ну я же не просто так пишу, а по следам настроек реально работающих магазинов. Эта функциию давно можно было включить на главной, основной странице первоначального запроса. И в 3.6. эта функция так же всегда была доступна: Администрирование > Помощь > Настройки поддержки,
Включить проверку случайным рисунком, Для всех, Только для незарегистрированных, Не использовать. После того, как пользователь при ответе переходит нак страницу переписки по индивидуальной уникальной приватной ссылке, проверки кодом (капчей) для последующих сообщений нет.