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

[expert74]

  В 18.04.2019 в 20:41, mpn2005 сказав:

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

Expand  

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

 

 

 

 

 

[expert74]

  В 18.04.2019 в 21:00, mpn2005 сказав:

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

Expand  

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

[sitecreator]

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

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

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

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

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

 

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

 

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

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

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

 

[mpn2005]

  В 19.04.2019 в 10:46, expert74 сказав:

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

Expand  

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

 

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

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

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

 

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

 

[expert74]

  В 19.04.2019 в 11:20, mpn2005 сказав:

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

Expand  

Версия ocStore 2.3.0.2.3

[expert74]

  В 19.04.2019 в 11:20, mpn2005 сказав:

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

Expand  

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

[mpn2005]

  В 19.04.2019 в 11:58, expert74 сказав:

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

Expand  

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

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

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

 

[Yesvik]

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

 

[Yesvik]

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

 

и ещё...

  В 18.04.2019 в 21: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

Expand  

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

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

[stickpro]

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

[Tom]

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

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

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

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

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

[expert74]

  В 20.04.2019 в 18:12, Tom сказав:

Айболит.

Expand  

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

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

[Luftwaffe]

  В 17.04.2019 в 08:10, kirill7 сказав:

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

 

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

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

 

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

index.php 413 \u043a\u0411 · 29 downloads

Expand  

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

[kirill7]

  В 24.04.2019 в 11:46, Luftwaffe сказав:

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

Expand  

 

 

  В 22.04.2019 в 04:33, expert74 сказав:

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

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

Expand  

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

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

[vasilev86]

?

[mpn2005]

  В 24.04.2019 в 16:27, kirill7 сказав:

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

Expand  

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

 

[Cosmonaut]

  В 18.04.2019 в 07:28, nikifalex сказав:

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

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

 

Expand  

session_id	varchar(32)	utf8_general_ci

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

[Cosmonaut]

  В 16.05.2019 в 11:56, nikifalex сказав:

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

Expand  

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

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

 

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

[AlexDW]

  В 16.05.2019 в 12:42, Cosmonaut сказав:

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

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

Expand  

 

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

[Cosmonaut]

  В 16.05.2019 в 16:26, AlexDW сказав:

 

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

Expand  

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