взлом, проникли в базы...

[expert74]

9 часов назад, mpn2005 сказал:

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

Да, пароли стояли простые...Нашел, что этот человек залил мне на сайт, вот картинка утилиты, скрывается под именем index.php только в отличии от стандартного весит 470 Кбайт, файл раскидан в разных местах.

 

 

 

 

 

[expert74]

9 часов назад, mpn2005 сказал:

Всё описанное в теме уже по 100 раз написано

Ну может быть, но по поиску ничего дельного не нашел.

[sitecreator]

Вообще, взлом, порой, происходит даже с соседнего аккаунта.

Скорее всего, не наш случай.

Но у меня был такой опыт.

Когда для вполне уважаемого хостера (и даже рекламируемого здесь)  я получил root-доступ на аккаунте обычного пользователя.

Разумеется, что описывать способ не буду, это вообще не для паблика.

 

Но у этого же хостера я также получал доступ (без root) к сайтам других аккаунтов за счет не вполне грамотной настройки сервера Мемкешт. Т.е. банально мог читать (и подменять) "файлы" (в Мемкешт) на совершенно посторонних аккаунтах.    Беседа с хостером на эту тему не дала результата, хостер не проникся идеей грамотного разделения доступа к серверу Мемкешт для разных пользователей (аккаунтов).

 

В моем модуле Компрессор (https://opencartforum.com/files/file/4572-image-compressor-watermark-webp-etc/) есть контроль за мемкешт-ключами.

Если вы видите левые ключи, то знайте, что это ключи другого пользователя.  Т.е. вы имеете доступ к чужим ключам и, соответственно, кто-то имеет доступ к вашим.

Рассказываю не как гипотетическую ситуацию, а как реальную проблему, которая приключилась с одним из заказчиков.

 

[mpn2005]

13 минут назад, expert74 сказал:

Запросил у хостера  список всех измененых\закачанных файлов - нашел еще один файлик. Выкладываю для тех кто столкнулся - называется read.php, вот что внутри 

Это тоже залитый файловый менеджер.

 

Какая у Вас версия движка?

Если OC2 то внимательно проверьте модификаторы в админке.

И посмотрите чтобы не было свежей даты установки и левых модификаторов.

 

И просматривайте каждый день access лог. Поиском ищите там php.

 

[expert74]

30 минут назад, mpn2005 сказал:

Какая у Вас версия движка?

Версия ocStore 2.3.0.2.3

[expert74]

38 минут назад, mpn2005 сказал:

левых модификаторов

Модификаторы были, выключил, удалять пока не стал, выкосить?

[mpn2005]

11 минут назад, expert74 сказал:

Модификаторы были, выключил, удалять пока не стал, выкосить?

Установите ocmod downloader, скачайте их себе и сохраните. После этого можно удалить.

Если взломы повторятся, то можно будет посмотреть код, что куда изначально заливалось.

Редко помогает, тк взломщики стараются отвести внимание от точки входа, чтобы не палить её. Но может и пригодится.

 

[Yesvik]

Судя по логу все рекомендации по смене паролей и защите админки - мимо кассы. Доберусь до компа посмотрю лог внимательнее.

 

[Yesvik]

Не видел что уже объяснили по поводу запросов

 

и ещё...

В 19.04.2019 в 00:00, mpn2005 сказал:

/index.php?route=product/product&path=199_200&product_id=1'xxx

/index.php?route=product/product&path=199_200&product_id=1"xxx

/index.php?route=product/product&path=199_200&product_id=1xxx

если будете так проверять - выключайте SEO_PRO

SEO_PRO не пропустит такой запрос и вы не поймёте есть уязвимость или нет.

[stickpro]

Где-то пробой,  и вам залили шелл

[Tom]

Начинается всё как правило  с админки.Пароли типа admin / admin , ну или 12345...Потом через встроенный инструмент "Бэкап / Восстановления" ловим ошибку, подменяя тип файла error.log или error.txt на php, который по сути обычный файловый менеджер. Далее, имеем доступ к бд, можем делать, что душе угодно, при этом не забывая подкидывать шеллы в другие папки, на случай если первый шелл был найден.

Обычно помогает чистка  вирусов, чем то типа Айболит.

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

Ну и не забываем, что причина возможна пришла к вам с соседних сайтов , к примеру с Word Press. Или же был найдет "дырявый" модуль, что в моей практике самая редко встречающаяся ситуация, если только человек преднамерено не ставил задачу сломать, точно зная наличие подобных дополнений у вас.

Змінено 20 квітня 2019 користувачем Tom

[expert74]

В 20.04.2019 в 23:12, Tom сказал:

Айболит.

Он шеллы не нашел, искал вручную. Бэкап почти помог, хитрый человек создал в корне папку под названием could, в которой лежал еще один файлик. Хочу сказать всем, кто отвечает - Вы мне очень помогаете, спасибо большущее, в конце темы выложу ошибки свои и технологию борьбы с бабайкой по пунктам.

Хостинг порадовал -  оказывается по умолчанию доступ к базам извне как здрасте.

[Luftwaffe]

В 17.04.2019 в 11:10, kirill7 сказал:

Недавно один владелец сайта обратился с такой же проблемой.

 

Некий человек так же обратился со скринами БД, админки, последних заказов.
Уверял в своей порядочности. Обещал исправить все уязвимости сайта(именно opencart'a) и продемонстрировать где что изменил, чтобы никто больше не смог использовать эти уязвимости.
Срочно поменяли все пароли, сделали бэкапы.

Все модули покупные.
После этого он "разозлился" и удалил файл из админки, после чего админка перестала работать.
И начал угрожать что будет обзванивать всех покупателей и распространять негативную информацию о сайте.
В общем владелец оплатил.
Тот человек что-то там поделал и сообщил что всё исправлено.
В итоге он написал что исправил несколько системных файлов которые избавят от RFI и RCE атак.
Что именно он сделал он так и не сказал, т.к. эта информация может стать доступна разработчикам и он потеряет заработок.

 

Сравнили файлы - ничего не изменилось, только один файл появился лишний, похоже забыл удалить:
/catalog/view/index.php
Файл прикрепил к сообщению.
 

index.php 413 \u043a\u0411 · 29 downloads

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

[kirill7]

4 часа назад, Luftwaffe сказал:

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

 

 

В 22.04.2019 в 07:33, expert74 сказал:

Он шеллы не нашел, искал вручную. Бэкап почти помог, хитрый человек создал в корне папку под названием could, в которой лежал еще один файлик. Хочу сказать всем, кто отвечает - Вы мне очень помогаете, спасибо большущее, в конце темы выложу ошибки свои и технологию борьбы с бабайкой по пунктам.

Хостинг порадовал -  оказывается по умолчанию доступ к базам извне как здрасте.

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

Змінено 24 квітня 2019 користувачем kirill7

[vasilev86]

?

[mpn2005]

1 час назад, kirill7 сказал:

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

Если доступ в админку был admin/admin или что-то подобное, то нет смысла сравнивать список модулей.

 

[Cosmonaut]

В 18.04.2019 в 10:28, nikifalex сказал:

ну ищите где незаэкранирован параметр в sql

типа $product_id но без (int) или escape

 

session_id	varchar(32)	utf8_general_ci

Это можно считать за дыру?)

[Cosmonaut]

43 минуты назад, nikifalex сказал:

что именно вас тут смутило?

ну ищите где незаэкранирован параметр в sql

типа $product_id но без (int) или escape

 

Смутил совет, так как я не шарю в БД, нашел отличие и хотел уточнить)

[AlexDW]

3 часа назад, Cosmonaut сказал:

ну ищите где незаэкранирован параметр в sql

типа $product_id но без (int) или escape

 

это искать нужно в самих запросах, а не в структуре БД

[Cosmonaut]

14 часов назад, AlexDW сказал:

 

это искать нужно в самих запросах, а не в структуре БД

Понял, принял) Благодарю)