Přehled odpovědí
-
Příspěvky
-
Aha já myslel ty obrázky na themeforest :)
Asi bych to viděl na nějaký problém v té šabloně
btw administrace šablony nemá žádnou ochranu proti CSRF.
Koukám, že v tom máme nějaký zmatek…
No such file or directory in /data/web/virtuals/26164/virtual/www/wp-admin/admin.php on line 13
na řádku 13 v souboru admin.php je komentář, žádné require_once.
Failed opening required ‘/data/web/virtuals/26164/virtual/www/admin.php’
soubor admin.php v standartní instalaci WP není v rootu!
Asi bych to celé smazal, stáhl si nový WordPress z http://wordpress.org a nainstaloval jej znova.
to vyskakovací okno jsem pořešil
nepořešil, pořád na stránce vyskakuje
Takže pořád by mě zajímalo, proč je tam bílý proužek, když do patičky nenapíšu
<? wp_footer() ?>tato funkce by v patičce být měla jinak vám nemusí fungovat některé pluginy
a když mám oboje vyplněno, tak se na webu pořád zobrazuje jenom čtvereček jako značka pro špatnou url obrázku a ani odkaz není načtený
je to proto, že obrázek na zadané URL neexistuje
Už jsem to samozřejmě hlásil autorům scriptu timthumb i autorům šablony.
Šablona je Kinetic od http://www.rockettheme.com (chybu bude patrně obsahovat každá šablona a to nejen pro WP – dělají je i pro joomlu, magento, drupal atd.)
Možná by ale nebylo marné informovat i pány ze sucuri.net, že nejdůležitější je odstranit příčinu a né jen následky ;)
Není za co, rád jsem pomohl.
Šablona využívá několik pluginů a vzhledem k tomu, že jsou od autorů šablony předpokládám, že to je jeden “balíček”.
I když jsem si na 99% jistý, že celý problém je v těch souborech timthumb.php tak bych to rád měl opravdu potvrzené z logů, ale to že hosting je u wedosu mi nějak vypadlo :(
Každopádně hlavně, že web už funguje bez problémů.
Tak už jsem na to zřejmě přišel, 8.srpna byla reportována tato bezpečnostní chyba – zatím bez reakce.
Script ve výchozím stavu neumožňuje načítání obrázků z externích serverů, ale z nějakého důvodu autoři ponechali povolené domény “flickr.com, staticflickr.com, picasa.com” atd. Problém je v tom, že pokud znám umístění scriptu na vašem serveru a na mém webu s doménou obsahující výše uvedené názvy (třeba flickr.com.cz) budu mít script s nějakým škodlivým kódem můžu jej přes soubor timthumb.php spustit na vašem webu (jednoduše řečeno).
Oprava této chyby spočívá v nastavení konstant
ALLOW_EXTERNALnaFALSE,ALLOW_ALL_EXTERNAL_SITEStaké na FALSE (řádek 32 a 33).Popřípadě smazat obsah pole
$ALLOWED_SITES(řádek 127-135). Nebudete sice moci přes tento script načítat obrázky z jiných domén než je doména webu, ale budete bez malware.Pro 100% jistotu, že už bude vše v pořádku bych, ale potřeboval ten log z hostingu…
Malinko jsem upravil oba soubory thumb.php v pluginech wp_rokbox a wp_roknewspager což jsou jen přejmenované soubory timthumb.php známé svými bezpečnostními dírami snad v každé předchozí verzi. A ačkoliv je poslední verze pokládána za bezpečnou (čti ještě nikdo nedokázal opak) tak bohužel bezpečná zřejmě není. A protože se tento script pro práci s obrázky vyskytuje ve stovkách možná tisících šablonách a pluginech nemám z toho vůbec žádnou radost…
Než ale budeme dělat nějaké závěry raději bych ještě nějaký čas počkal zda tato malá úprava opravdu vyřešila váš problém. Nebo pokud by to šlo, dost by mně zajímal access log ze serveru (z poslední doby – nejlépe tak týden, samozřejmě na mejl). Pořád ještě nevím konkrétně jaké chyby v tom souboru timthumb.php ta potvora využila, zatím to nedokážu zopakovat…
ale hlásí mi to chyby
Jaké chyby?
Tak to přece jen není planý poplach, škodlivý kód se vždy objeví v souboru index.php v rootu. Problém je ten, že nemůžu přijít na to jak se tam dostane a v době kdy jsem se na něj koukal prvně tam nebyl…
Každopádně poslední změna souboru je 18:07 a to když jsem ho vyčistil a zatím je nezměněn.
EDIT:
malinka úprava, doporučuji změnit hesla (FTP, MYSQL, administrace)
Pokud i teď dojde k infekci tak by možná ještě pomohl log apache, jinak už fakt nevím a začal bych znovu s novým WP a jinou šablonou.
Aktuálně teď se mi stránka zobrazí bez jakéhokoliv upozornění, takže předpokládám, že snad je to ok.
Jen mně zaráží, že doteď jsem neviděl nic co by se dalo pokládat opravdu za nějaké nebezpečí na vašem webu. Pokud sucuri něco na vašem webu odstranila tak by snad mohli napsat nějaké konkrétní informace co že to vlastně bylo (popřípadě alespoň v jakém souboru), už třeba jen proto, aby jste tomu mohl v budoucnu předejít.
Z google se nedá zjistit nějaké další informace? Například konkrétně na kterých stránkách byl škodlivý kód nalezen?
Z toho co vím vyplývá jediné a to, že něco na vašem webu označil google za škodlivé (můžet to být klidně jen odkaz na jiný web obsahující něco škodlivého), tomu by i nasvědčovalo to, že to nalezl jen na pouhých 15-ti stránkách z celkových 80. Možná to byl jen odkaz (reklama?) na jiný server (v menu online casina) nebo odkazy z unibetu (také vedou na jiné servery). Těžko říct bez nějakých podrobnějších informací.
Každopádně pokud by se to opakovalo asi bych se nebál použít jinou šablonu vzhledu, vaše je řekl bych extrémně složitá na to co má dělat (mraky ajaxu, framework, vlastní pluginy šablony atd atd) a objevit nějaké zadní vrátka v tolika tisících řádcích zdrojového kódu není zrovna jednoduché… Ostatně to co nakonec vidí uživatel v prohlížeči je skoro to samé co by zvládla malinko upravená výchozí šablona.
Kouknul jsem na to a výsledek je takový:
1) nenašel jsem žádný škodlivý kód, ani v šabloně ani v pluginech
2) nenašel jsem žádné odkazy nebo cokoliv podivného
3) WordPress, všechny pluginy a šablony jsou aktuální a nenašel jsem žádnou zmínku o nějaké bezpečnostní chybě v současných verzích
4) web jako takový je relativně dobře zabezpečen
Takže nějak nerozumím několika věcem:
1) jak jste poznal, že web je opět infikován i když jste jej celý přeinstaloval? (to, že prohlížeč vrací nějakou hlášku mně nezajímá, mně zajímá konkrétní soubor, script, funkce, odkazy atd atd)
2) co že konkrétně sucuri našel a odstranil (v jakých souborech atd.), protože ve výsledku píše “malware not identified” (viz zde)
3) Jak můžete vědět, že web je do 24. hodin opět infikovaný, jak se to projevilo? – dostat se z blacklistu googlu trvá docela dlouho i když je web čistý, určitě to není záležitost na 24hodin
Jinak pro info McAfee Site Advisor na webu nevidí žádný problém (viz zde).
halouzka: Sranda je to, že sucuri vám čistí web i když sami neví co je na něm škodlivého, jako škodlivý jej označili právě pouze kvůli tomu, že jej blokuje google. Google na vašem webu údajně našel trojana a to pouze na 15-ti stránkách z 80 což je samo o sobě podivné, většinou bývá malware includován do všech stránek a né pouze do některých.
Mě spíše zajímá proč jsem schopen získat z úvodní stránky dva rozdílné zdrojové kódy (žádný není nijak škodlivý – jsou pouze malinko rozdílné). Jde o XHR request nějakého pluginu…
EDIT: zdroje rozdílné nejsou pouze při načítání stránky je nějaký XHR request zřejmě ajaxem, který načte tu samou stránku, kterou se pokoušíte zobrazit. Možná bych se ani nebál tvrdit, že jde o planý poplach. Bez podrobnějšího prozkoumání, ale těžko říct…
U výchozí instalace tento soubor není, ale WP při requestu na “robots.txt” tento soubor vygeneruje a zobrazí jej (můžeš si to vyzkoušet zadáním wp-blog.cz/?robots=1 – dostaneš výchozí generovaný robots pokud zadáš URL k fyzicky existujícímu souboru wp-blog.cz/robots.txt – dostaneš skutečný soubor robots)
Bych to viděl na stejný problém jako tady https://www.separatista.net/forum/topic.php?id=1283 :)
Viděl bych to na zmršené práva u souborů, na většině hostingů je webFTP tedy webové rozhraní pro přístup k souborům na serveru a v tomto webovém rozhraní bývá také možnost resetovat oprávnění ke všem souborům na hostingu. Zkuste jej použít většinou to tento problém vyřeší (tento reset může být i někde v administraci hostingu, zkuste hledat).
Samozřejmě ale nejrychlejší bude kontaktovat podporu jak napsal admin.
admin: WP si sice soubor robots.txt generuje automaticky, ale díky pravidlům v htaccess souboru má vždy přednost soubor na serveru pokud existuje, pokud jej tedy vytvořím bude se zobrazovat můj vytvořený a nikoliv ten generovaný WordPressem. A pokud jsou chybně nastavena práva pro čtení u souborů na serveru dostane uživatel chybu 403 – tedy tento případ.
Bez podrobnějších informací to tady nikdo nevyřeší, chce to alespoň URL webu.
Hosting WEDOS je ZATÍM bez problémů co se týče bezpečnosti, takže bych to viděl na nějakou skulinu v šabloně nebo nějakém pluginu.
Pokud mi pošlete nějaké info + přístup na FTP můžu ten problém vyřešit (lukenzi@gmail.com).
Použít FTP?
Chyba je samozřejmě v hostingu. Volba safe_mode je ve verzi PHP 5.3 označena za zastaralou a v budoucích verzích bude zcela odstraněna. To že administrátoři neumí zabezpečit svůj hosting bez použití safe_mode o něčem svědčí…
Takže můžu jen poradit změňte hosting (třeba za WEDOS), ušetříte a nebudete muset řešit problémy tohoto typu.
