Pomoc! - neustálé automatické vypínání platebních metod - M1

Ahoj! Mám docela velký problém. Eshop mám aktualizovaný na 1.9.3.10. Do teď běžel normálně, ale od začátku října mám problém, že jednou za den se mi vypnou mnou nastavené metody platby a zákazník nemůže nic objednat.
Před cca týdnem jsem vlezl do administrace a byl zde nově nainstalovaný modul file manager. Já ho neinstaloval. Odstranil jsem ho, nastavil správně platební metody, ale to nepomohlo. Takže jsem celý eshop obnovil ze zálohy na hostingu (cca 14dní zpátky stará záloha), změnil jsem cestu k administračnímu prostředí, přidal captcha kód k přístupu do administračního prostředí a k dalším položkám (registrace, nákup jako host atd.), změnil jsem i heslo pro přístup do administrace. Pár dnů to bylo ok, ale dnes zase volají zákazníci, že jim nejde dokončit objednávka a ve volbě platby není žádná položka a samozřejmě byly platební metody zase opět vypnuty.

Prosím o pomoc! Je to velice urgentní!

v cron.php mám tento kód
<?php
/**

  • Magento
  • NOTICE OF LICENSE
  • This source file is subject to the Open Software License (OSL 3.0)
  • that is bundled with this package in the file LICENSE.txt.
  • It is also available through the world-wide-web at this URL:
  • http://opensource.org/licenses/osl-3.0.php
  • If you did not receive a copy of the license and are unable to
  • obtain it through the world-wide-web, please send an email
  • to license@magento.com so we can send you a copy immediately.
  • DISCLAIMER
  • Do not edit or add to this file if you wish to upgrade Magento to newer
  • versions in the future. If you wish to customize Magento for your
  • needs please refer to http://www.magento.com for more information.
  • @category Mage
  • @package Mage
  • @copyright Copyright © 2006-2018 Magento, Inc. (http://www.magento.com)
  • @license http://opensource.org/licenses/osl-3.0.php Open Software License (OSL 3.0)
    */

// Change current directory to the directory of current script
chdir(dirname(FILE));

require ‘app/bootstrap.php’;
require ‘app/Mage.php’;

if (!Mage::isInstalled()) {
echo “Application is not installed yet, please complete install wizard first.”;
exit;
}

// Only for urls
// Don’t remove this
$_SERVER[‘SCRIPT_NAME’] = str_replace(basename(FILE), ‘index.php’, $_SERVER[‘SCRIPT_NAME’]);
$_SERVER[‘SCRIPT_FILENAME’] = str_replace(basename(FILE), ‘index.php’, $_SERVER[‘SCRIPT_FILENAME’]);

try {
Mage::app(‘admin’)->setUseSessionInUrl(false);
} catch (Exception $e) {
Mage::printException($e);
exit;
}

umask(0);

$disabledFuncs = array_map(‘trim’, explode(’,’, strtolower(ini_get(‘disable_functions’))));
$isShellDisabled = is_array($disabledFuncs) ? in_array(‘shell_exec’, $disabledFuncs) : true;
$isShellDisabled = (stripos(PHP_OS, ‘win’) === false) ? $isShellDisabled : true;

try {
if (stripos(PHP_OS, ‘win’) === false) {
$options = getopt(‘m::’);
if (isset($options[‘m’])) {
if ($options[‘m’] == ‘always’) {
$cronMode = ‘always’;
} elseif ($options[‘m’] == ‘default’) {
$cronMode = ‘default’;
} else {
Mage::throwException(‘Unrecognized cron mode was defined’);
}
} else if (!$isShellDisabled) {
$fileName = escapeshellarg(basename(FILE));
$cronPath = escapeshellarg(dirname(FILE) . ‘/cron.sh’);

        shell_exec(escapeshellcmd("/bin/sh $cronPath $fileName -mdefault 1 > /dev/null 2>&1 &"));
        shell_exec(escapeshellcmd("/bin/sh $cronPath $fileName -malways 1 > /dev/null 2>&1 &"));
        exit;
    }
}

Mage::getConfig()->init()->loadEventObservers('crontab');
Mage::app()->addEventArea('crontab');
if ($isShellDisabled) {
    Mage::dispatchEvent('always');
    Mage::dispatchEvent('default');
} else {
    Mage::dispatchEvent($cronMode);
}

} catch (Exception $e) {
Mage::printException($e);
exit(1);
}

Určite to vypína ten cron?

To by sa mohlo dať ľahko overiť… Cron súbor sa dá spustiť z konzoly a ak sa vypnú tie platobné metódy, tak to bude tým… ak nie, tak to nebude mať s cronom nič spoločné a skôr sa treba pozrieť či Vám niekto nehackol server (to by vysvetľovalo tú novo nainštalovanú extensnu)

kamarát mal však troch väčší problém… po tom ako ho hackli (neaktualizoval) mu nastavali platobnú metódu cez paypal na cudzí účet…

Zdravím, ten modul pokud se jmenoval File System nebo File Manager, tak to bylo hacknuté a útočník pak může převzít kontrolu nad systémem a připravit si tam backdoor, který mu umožní kdykoliv později škodit. Většinou vzniknou nové fiktivní admin účty a přibudou nové .htaccess soubory nebo se dějou jiné neplechy. Mohu na to mrknout, kdyby byl zájem. Nicméně jde často o hodiny nad čištěním a pak další nad patchováním a zabezpečením. Zkuste Vaši URL eshopu prohnat tímhle https://www.magereport.com/

Teď mi tak došlo, že cron to vypínat nebude…mám ho nastavenej po 5minutách, takže by se každejch 5minut musely vypnout platební metody a to to nedělá…vypnou se jen jednou denně.

Ohledně toho Paypalu…ten se mi právě vždycky automaticky zapne a vše ostatní se vypne. Takže když to zjistím, tak musím paypal vypnout a zapnout platební metody, které chci já.

Co s tím? V tomhle jsem bezradnej…

Webhosting mám přes Stable.cz a v serveru se tedy nemohu hrabat. Myslíte, že by mohl být napaden tento sdílený hosting? Zkusím je kontaktovat.

Zdravím,
pokud máte web napaden (což není jisté, může to být i něco jiného), tak nebude lehké se toho zbavit.
Útočníci jsou dost vynalézaví, jak si udělat nějaký backdoor.

Už jsme pár takových případů řešili a byla to práce na několik dnů.
Zaměřil bych se na složku media, to je dost oblíbené místo kam něco schovat.

Dost v takových případech pomáhá, pokud používáte nějaký pokročilý systém deploymentu kódů, nebo používáte alespoň nějaký verzovací systém (např. git). Pak se změny hledají lépe.

Pokud nic z toho nemáte, můžete se pokusit sestavit e-shop celý znovu.
Tj. čisté magento (už je verze 1.9.4.3), nasadit prověřené moduly (také nejlépe v nejnovější verzi),
přenést design (tam pozor, tam by mohl být nějaký škodlivý kód) přeimportovat data a je to :slight_smile:

Je ale zajímavé, že když jsem obnovil celý eshop ze zálohy cca 14dnů staré, kdy to fungovalo vše v pohodě, tak že to stále dělá.
Být někde uložený škodlivý kód, tak bych se ho tím zbavil nebo ne?

Děkuji za každou další radu.

Pokud se ti sám od sebe aktivuje PayPal, pak je web haknutý. Zkontroluj kód souboru /includes/config.php, jestli neobsahuje něco podezřelého…

Jinak více info zde

obsahuje pouze toto:

#define(‘COMPILER_INCLUDE_PATH’, dirname(FILE).DIRECTORY_SEPARATOR.‘src’);
#define(‘COMPILER_COLLECT_PATH’, dirname(FILE).DIRECTORY_SEPARATOR.‘stat’);

To je OK, pak se zaměř na soubory, které jsou spouštěny při každém zobrazení stránky a porovnej je se soubory z výchozí instalace M1.9.3.10, jako například:
app/Mage.php
lib/Varien/Autoload.php
index.php
app/code/core/Mage/Core/functions.php

Kdybys věděl, kdy k infekci došlo, zkus si vypsat seznam souborů, které byly změněny např v posledních 10 dnech, v konzoli stačí spustit příkaz:

find /cesta/k/adresari/magenta -type f -mtime -10

Taky zkontroluj složky media a var, jestli neobsahují nějaký php kód, reinfektor se může ukrývat i tam.

Setkal jsem se i s trikem upraveného png nebo jpg souboru, který se tváří jako správný obrázek, ale na konci je <?php kód, který se při načtení obrázku přes prohlížeč provede.

Myslím, že obnova ze zálohy nepomůže. Měl jsem na mysli sestavit znovu z čistých kódů.
Je možné, že v té záloze už jsou nějaké úpravy útočníka ale to není důležité, protože tam je pravděpodobně i původní díra, kterou se tam dostal. Magento 1.9.3.10 je rok stará, tj. obsahuje spoustu děr, které již byly v následujících verzích opraveny.

Za jednoduchý pokus stojí obnoviť to zo zálohy, a zaktualizovať na najnovšiu verziu… Obnova zo zálohy musí byť vykonaná v novom adresári, lebo prepísanie súborov v starom adresári znamená, že pridané súbory backdoorov sú stále použiteľné…

Ak nepomôže ani to, znamená to, že 14 dni stará záloha je už napadnutá. Alternatívne bolo ukradnuté admin heslo a cez remote api sa nastavuje toto…

Nám napríklad každú chvíľku hackujú downloader… tak som do index.php dal:

if(count($_POST) > 0){
   file_put_contents("blockips.txt",$_SERVER["REMOTE_ADDR"].";".time().";".json_encode($_POST)."\n",FILE_APPEND);
}

To do súboru blockips.txt zapíše zoznam pokusov o hacknutie, a tie potom pridávam konfigurácie nginxu ako hackarov ktorých blokujem… Za mesiac je to cca 500 nových ipčiek…

Možno je čas už prejsť na verziu 2.3.3 ? :slight_smile: Tá verzia je už konečne použiteľná pre prod…

To asi ťažko… php kompiler spracováva iba php súbory, a teda jediný spôsob ako toto vykonať je zavolať include na súbor obrázka… teda musí byť najskôr issue v php súbore, a potom musí byť modifikovaný ešte aj ten obrázok…

iba v prípade fatálne chybného nastavenia apachu alebo nginxu by to mohlo priamo spracovávať png súbory cez php processor, čo je veľmi veľmi nepravdepodobné… Zmena konfigurácie servera vyžaduje väčšinou sudo oprávnenia, a to asi ťažko bude mať www-data user nastavené :slight_smile:

Pokud někdo se dokáže dostat na server, nainstalovat nějaký modul pro nahrávání souborů, pak zrovna tak může upravit .htaccess takovým způsobem, že php interpret bude prováže png soubor jako php kód.
Ano vyžaduje to jistou úroveň nadstrandardního opravnění, ale nic není nemožné a jenom upozorňuji na co by bylo dobré zkontrolovat. Je to skvělý způsob jak si připravit backdoors i když dojde k odhalení útoku a částečné nápravě. Tedy jako jeden z checků je zkontrolovat, že všechny media soubory (gif, jpg, png, a další) jsou validní soubory daného formátu.

Přináším novinky ohledně napadení mého eshopu. Po obnovení ze zálohy jsem změnil všude hesla, i na serveru (Nginx), databáze atd, změnil jsem přístupovou cestu do admin a přidal jsem další zabezpečení serveru - toto:

  1. https://support.hypernode.com/knowledgebase/secure-magento-cacheleak/

  2. https://support.hypernode.com/knowledgebase/how-to-protect-your-magento-store-against-brute-force/

Všude jsou zapnutý captcha ověření. Zatím vše funguje, tak jak má.

Jen se mi teda občas registruje nějaký zákazník jako například: jméno -piterabak příjmení -piterabakVH a mail pi.t.e.r.mor.g.a.ns.p.o.rt.s.to.re.w.o.rld.2.0.1.6@gmail.com

Jde se těchto nechtěných registrací uživatelů XY zbavit? Zajímavé, že se rigistrujou i přes captcha ověření.

Mockrát Vám děkuji za cenné rady, pokud se problém objeví znovu, tak budu pátrat dál dle Vašich rad.

Přechod na Magento 2+ by byl dobrý, ale zatím je pro naší firmu nereálný, z důvodu vysoké ceny serveru, na kterém jde Magento 2 funkčně rozjet. Magento 1 není, tak náročné a na sdíleném hostingu je za dobré peníze (Stable.cz).

Captchu, kterou používáte a je ve základu M1 je některými roboty zlomitelná.

Lepší přejít na novější verzi https://www.google.com/recaptcha/intro/v3.html . Zatím jsem nezaregistroval, že by nějaký robot přešel přes v3.

Jak na ní přejít? Lze do Magenta nahrát nějaký kvalitní modul? Nebo jak ji lze zprovoznit?

Předem děkuji za info:-)

Nejsnažší je koupit a nainstalovat modul ReCaptcha od Amasty - mám na zbytku M1 shopů (cca 10 kousků) a funguje skvěle. Žádný nekompatibility, technický komplikace a přitom filtruje roboty u loginu, registrace, kontaktního formuláře, přihlášení k odběru newsletteru atd.