Insaider.lt hacked!

Ištikimesni insaider.lt tinklaraščio lankytojai tikriausiai pastebėjo, kad nuo vakar vakaro mano tinklaraštis buvo nulaužtas. Šiandien ryte vėl viskas veikia, todėl tik nedidelė lankytojų dalis spėjo pasigrožėti padariniais. Nenusiminkite, visus sugadintus failus ir kitas grožybes išsaugojau ir pademonstruosiu šiame įraše.

Blogą nulaužė kažkoks Indonezijos „hakeris” pasivadinęs Fran_73 (dabar google suindeksuos šį straipsnį ir programišius galės maudytis šlovės spinduliuose). Realios žalos nepadarė, tiesiog sugadino index.php failą ir sukūrė savo pristatomąjį pradinį failą (atsisiųsti failą .txt formatu). Savo pristatomajame puslapyje patalpino jo supratimu labai gražių Indonezijos panelių nuotraukas (tikriausiai lietuvaičių nematė). Viena nuotrauka tiesiogiai iš facebook buvo naudojama kaip paslėptas fono paveikslėlis (šio straipsnio iliustracija), o kita foto su iki puses uždengtu kūnų buvo kaip pagrindinė iliustracija (nuotrauka šone).

Taip pat sukūrė auto.php failą, kurį naudojo siuntinėti spamui el. paštu (atisiųsti failą .zip formatu). Pagrindiniame aplankale radau užkrėstą failą allnet.jpg, kurį teko ištrinti, nes antivirusinė pradėjo spygauti (nėra prasmės virusą viešai platinti šiame įraše).

Kokiu būdu buvo įsilaužtą iki šiol nežinau. Tačiau tai labai panašu į wodpress.com tinklaraščių atakas. Priėjimo prie ftp negavo, todėl greičiausiai bus kaltas koks nors įskiepis. Naudoju visus legalius įskiepius su naujausiomis versijomis, wp versija taip pat šiuo metu naujausia (3.3.1). Pateikiu šiuo metu naudojamų įskiepių pavadinimus ir versijas:

  • Akismet 2.5.4
  • All in One SEO Pack 1.6.13.8
  • BulletProof Security .46.7 (įrašyta po nulaužimo)
  • Conditional Captcha for WordPress 3.2.4
  • Facebook Revised Open Graph Meta Tag 0.5
  • FeedBurner FeedSmith 2.3.1
  • Google XML Sitemaps 3.2.6
  • IntenseDebate 2.9.3
  • lbcd78 Meta Keyword Generator 0.7
  • Lightbox 2 2.9.2
  • No IE Welcome 1.0.1
  • Page Lists Plus 1.1.8
  • Recent Google Searches Widget 1.40
  • SyntaxHighlighter Plus 1.0b2
  • Target Blank In Posts And Comments 3.2
  • WordPress.com Popular Posts 2.5.2
  • WordPress.com Stats 1.8.5
  • WordPress Related Posts 1.2
  • Puslapių numeravimas 2.81
  • WP-Polls 2.62
  • WP Security Scan 3.0.9 (įrašyta po nulaužimo)
  • WPtouch 1.9.37
  • WP YouTube Player 1.5

Galbūt jūsų manymų šiame sąraše yra nesaugių įskiepių? Keisčiausia, kad daugelį įskiepių naudoju ir kituose wp projektuose, tačiau buvo nulaužtas tik šis.

Kaip bebūtų, šiuo metu viskas veikia. Dėka mano pažįstamo, ipcoders.com hostingo administratoriaus problema buvo išspręsta per keletą minučių: atstatytas backup’as, pašalinti užkrėsti failai, įdiegta antivirusinė, kuri nuolat skenuoja visus mano talpinamus failus, pakeisti visi slaptažodžiai… todėl tokių „stebuklų” turėtų nepasitaikyti. Iš savo pusės su .htaccess apsaugojau wp-admin aplankalą, įdiegiau papildomos wp apsaugos įskiepius.

Daugeliui wordpress tvs naudotujų, kurie skaito šį įrašą, sukilo nerimas, kad galbūt wordpress tvs yra nesaugi ir jų projektams iškyla grėsmė. Deja, taip tikrai nėra. Jei naudojate naujausia 3.3.1 versiją, jums niekas negrasia. Norėdami užtikrinti saugumą įsidiekite vieną iš wp apsaugos įskiepių ir atidžiai perskaitykite Povilo straipsnį apie wp saugumą bei Ričardo patarimus.

EDIT: Problema išspręsta dėka Marijaus Urbono. Saugumo spraga buvo rasta wp temos timthumb.php faile. Informaciją, kaip ją pašalinti rasite šiuose straipsniuose: How To Fix The Security Issue in Timthumb ir How to fix Timthumb security issue?.

49 atsakymai į “Insaider.lt hacked!”

  1. Kiek per mažai duomenų, kad daryti konkrečias išvadas. Nepaisant to, galiu spėti, kad:

    1. Buvo silpnas slaptažodis, o wp-conf.php nurodyti FTP duomenys, kad nereiktų, atnaujinant, kaskart įvedinėti. Tiesa, abejotina, kad būtent taip buvo "įsilaužta" – skaityti 2 punktą…

    2. Kiek labiau esu tikras, kad su katalogų ir failų teisėmis (chmod) kažkas ne taip. Siūlyčiau įsitikinti, kad visi katalogai, išskyrus wp-content/uploads, yra 0755, o failai – 0644. Su 1 punktu gaunasi neblogas kokteilis…

    3. Net labai tikėtina, kad pagrindinė spraga, vis gi, yra theme… Naudojamas PersonalPress, kurį sukūrė Elegant Themes, o jie savo theme beveik visada naudoja TimThumb… O pastarajame buvo palikta labai rimta spraga, dėl ko buvo "nulaužti" tūkstančiai WP tinklalapių ar tinklaraščių. Žinoma, jei theme buvo visada atnaujinama, problema greičiauasiai yra ne TimThumb.

    4. Neaišku, kokia buvo naudojama WP versija "įsilaužimo" metu – 3.3.0 versiją buvo rekomenduojama atnaujinti į 3.3.1

    Žinoma, visa tai, remiantis teiginiu, kad kad "įsilaužta" pasinaudojus spraga būtent WP (theme, plugins), o ne serveryje. Bent kiek žinau, serveryje yra tik vienas tinklaraštis – šis.

    Beje, žodį "įsilaužta" kabutėse rašau ne šiaip, kai kalbama apie WordPress. Kiek buvo tokių "įsilaužimų", visais atvejais paaiškėjo, kad spragos buvo ne WP. Dažniausiai "įsilaužiama" dėl pačių WordPress naudotojų klaidų. Gana dažnai "įsilaužiama", kai spraga yra theme. Ypač, jei theme nėra oficialiai patalpintas WordPress, kaip ir šiuo atveju. "Įsilaužimų" per spragas įskiepiuose pasitaiko kana retai – visi WordPress oficialiai patalpinti įskiepiai taip pat patikrinami.

    Pats asmeniškai WordPress pagrindu esu sukūręs beveik 200 tinklalapių ir dar nebuvo nei karto, kad kas "įsilaužtų". Dažniau buvo išnaudojamos permalinks ir wp-cron silpnybės, kai buvo galima tiesiog "suvalgyti" visą serverio atmintį ir jį "užlenkti". Tiesa, nuo 3.3.0 versijos permalinks problema sutvarkyta, o tiesioginių užklausų į wp-cron galima išvengti su WP-Cron Control.

    1. Tikriausiai kalta tema, nors ji dėka Džiugo gauta legaliai, tačiau nežinau kuri versija, nes įkėliau senos temos css ir rodo 1.1 (nors žinau, kad buvo daug naujesnė).
      Gaila, baigėsi Džiugui prenumerata ir negali atsiųsti naujesnės versijos…

  2. Em… O tai kaip access.log? Negi serverio administratoriai negali tau jo atsiųsti? Turėjau ir aš tokių nuotykių kada teko padėti kitiems išsiaiškinti kaip buvo nulaužta. Pirmiausiai ką reikia žiūrėti tai access.log failą, kuriame galima pamatyti kur buvo kreiptąsi. Tuo labiau, kaip suprantu, tu esi įsitikinęs, kad nulaužta ne per FTP, o kažkur iš wordpress pusės.

    Nedidelis patarimas: o gal tau nereikia tiek daug visokių įskiepių? Taip pat yra labai blogai neišsiaiškinti kaip buvo nulaužta, manau ir pats supranti kodėl.

    Nors nemačiau nulaužtos svetainės, bet tikiuosi susitvarkysi ir tokių dalykų nebus, nes esu tavo tinklaraščio skaitytojas.

    1. Gavau, bet tik šios dienos, nes po viso acc backup atstatymo nėra galimybės gauti senesnių duomenų.
      Jei Marijus teisus, tuomet saugumo spraga ištaisyta. O dėl įskiepių, galbūt būtų galima kažko atsisakyti…
      Kaip atrodė nulaužta svetainė galima pamatyti tiesiog atsisiuntus ir į hostingą įsimetus šį html failą http://insaider.lt/wp-content/uploads/insaider-ha

  3. Džiugu, kad nesunkiai susitvarkei, nors vis tiek labai įdomu kodėl taip nutiko – kur spraga… Beje, aš naudoju dar vieną įskiepį saugumo sumetimais: Login Logs, jis kaupia duomenis apie bandymus prisijungti prie admin panelės. Jei pamatyčiau kad kažkas "atakuoja" prisijungimus – pirmiausia užbaninčiau "atakerio" IP.
    Kitas įskiepis kuris sukeltų nepatogumų hackeriams – Login Lock Down, kuriame galima nustatyti po kelių nesėkmingų bandymų prisijungti – kuriam laikui bus užrakinta prieiga prie prisijungimo lango. Kitaip sakant kelissyk suklydęs hackeris jau bus priverstas naudoti kažkokius proxy, ar dar ką – tiesiogiai jungtis jau nebegalės.
    Įdomu ką daro tie nauji saugumo įskiepiai, kuriuos susidiegei po nulaužimo? 🙂 BulletProof Security – ką jis saugo – prisijungimą, ar kažką visai kito?

    1. Nesunkiai susitvarkiau dėka gero hostingo administratoriaus, kuris visakeriopai padėjo. Saugumo spraga buvo timthumb.php faile, kurį derėtų visiems pasikeisti pagal Marijaus nurodytas instrukcijas.
      BulletProof Security parodo kokios saugumo spragos yra. Iš tiesų jis nėra naudingas, jei pats turi galvą ant pečių. Jei svetainėje naudojami visos apsaugos, kurios paminėtos Povilo bei Ričardo straipsnyje, tuomet tie "apsaugos" įskiepiai nereikalingi.

  4. Perskenavus su antivirusine buvo rasti infekuoti failai visuose mano projektuose. Tikriausiai Marijus buvo teisus dėl minėtosios timthumb klaidos.
    File Virus Disinfect * Quarantine Destroy Ignore
    mail/wps.lt/tomas/cur/1317551236.H101450P2202.maincore.ipcoders.com,S 2824:2,S
    public_html/insaider.lt/wp-content/themes/PersonalPress/cache/external_69fe6694b6c6f71234f258694f02434c.php PHP.Shell-22
    public_html/insaider.lt/wp-content/uploads/auto.zip PHP.Mailer-7
    public_html/videosmile.lt/wp-content/themes/Polished/cache/external_564e37ee22b9419ef196ecd7675d0e42.php PHP.Hide
    public_html/videosmile.lt/wp-content/themes/Polished/cache/external_5ea8c14c2833e42b7031c73422398393.php PHP.Hide
    public_html/fad.lt/wp-content/themes/striking/cache/images/external_7e30804b68501ac775c35e1db21b502f.php PHP.Hide

  5. Atrodo, reiks kada rast laiko ir parašyti išsamų įrašą apie WordPress saugumą… Tam tikra prasme, daugelis čia išvardintų saugumo įskiepių yra beveik beverčiai… Jie gali apsunkinti bruteforce atakas, apsunkinti nustatyti, kokia WP versija naudojama ir t.t., bet realiai "neužlopo" jokių skylių. Kitaip tariant, įskiepiai "dėl visa ko, vardan ramybės".

  6. Radau net klaidų logą, kuriame matosi kaip fad.lt buvo fandyta sukurti paveikslėlį su .php plėtiniu
    [01-Sep-2011 23:34:19] PHP Warning: imagecreatefromgif() [function.imagecreatefromgif]: '/home/wps/public_html/fad.lt/wp-content/themes/striking/cache/images/external_7e30804b68501ac775c35e1db21b502f.php' is not a valid GIF file in /home/wps/public_html/fad.lt/wp-content/themes/striking/includes/timthumb.php on line 381
    [01-Sep-2011 23:34:19] PHP Warning: Cannot modify header information – headers already sent by (output started at /home/wps/public_html/fad.lt/wp-content/themes/striking/includes/timthumb.php:381) in /home/wps/public_html/fad.lt/wp-content/themes/striking/includes/timthumb.php on line 828
    [01-Sep-2011 23:34:20] PHP Warning: imagecreatefromgif() [function.imagecreatefromgif]: '/home/wps/public_html/fad.lt/wp-content/themes/striking/cache/images/external_dd58e9270114ad1f95c0e3da514a2b6c.php' is not a valid GIF file in /home/wps/public_html/fad.lt/wp-content/themes/striking/includes/timthumb.php on line 381
    [01-Sep-2011 23:34:20] PHP Warning: Cannot modify header information – headers already sent by (output started at /home/wps/public_html/fad.lt/wp-content/themes/striking/includes/timthumb.php:381) in /home/wps/public_html/fad.lt/wp-content/themes/striking/includes/timthumb.php on line 828

    kaip supratau bandyta per visus mano projektus laužtis, bet pavyko tik į insaider.lt?

          1. šiaip visuose projektuose yra tas failas ir su tokiu pačiu pažeidimu, tik kažkodėl kitur neįsilaužė.
            [16-Nov-2011 23:07:21] PHP Warning: imagecreatefromgif() [function.imagecreatefromgif]: '/home/wps/public_html/videosmile.lt/wp-content/themes/Polished/cache/external_564e37ee22b9419ef196ecd7675d0e42.php' is not a valid GIF file in /home/wps/public_html/videosmile.lt/wp-content/themes/Polished/timthumb.php on line 370
            Dabar visur pakeičiau tuos failus timthumb.
            Dar kartą didelis, dėkui. Rytoj tikriausiai vėl viskas būtų nulūžę…

          2. na juose taip pat buvo ta eilutė
            $allowedSites = array (
            'flickr.com',
            'picasa.com',
            'img.youtube.com',
            'upload.wikimedia.org',
            );

          3. O tu palygink abu failus su kokiu diff. Juk kai klausei "kaip supratau pakanka pašalinti funkcija, kuri leidžia imti paveikslėlius iš nutolusių serverių", nesileisdamas į smulkmenas atsakiau "Grubiai tariant, taip". Nes klaida yra "giliau", pačiame TimThumb script'e. Sprendimas uždrausti naudoti išorines tarnybas tiesiog paprasčiausias, nekeičiant viso TimThumb failo. O eiliniam vartotojui, nusipirkusiam tokią theme net ir toks paprasčiausias sprendimas gali būti labai sudėtingas…

          4. na taip, jie visi visiškai skirtingi. Jei pašalinus minėtąją funkciją grėsmė išnyko, tuomet detaliau gilintis į skriptą ir neverta.

          5. Todėl TimThumb komanda pakoregavo script'ą, kad vartotojams nereiktų kišti nagų. Taigi, tie, kurie galėjo atnaujinti theme, tokių problemų ir išvengė.

  7. Geras įrašas. Padėjo rasti laiko padaryti backupus ir atsinaujinti savo saitus.

    Šiaip smalsu.. kodel į padėjusio admino saitą dėjai ne linką o tik tekstu įrašiai ?

    1. ta prasme reikėjo straipsnio apačioje prirašyti nuorodą į Marijaus tinklaraštį? Arba aš išvis nesupratau, ką norėjai pasakyti…

      1. "Dėka mano pažįstamo, ipcoders.com hostingo administratoriaus problema buvo išspręsta per keletą minučių"

        turejau galvoje sita 🙂

        O marijaus tnklapis matosi 😀

  8. Manau būtų neprošal tau padėkoti, kad pasidalinai savo nuotykiais. Privertė susimastyti dėl savo tinklaraščio saugumo, dėl kurio iki šiol nelabai rūpinausi 🙂

  9. Tavo temos 1.1 versija yra pati pimoji. Praeitais metais naujausia buvo 3.0 🙂 Beje, 2.8 versijoje buvo padaryti tokie pakeitimai:
    – Removed timthumb due to known vulnerabilities
    * deleted timthumb.php, cache and temp folders

    1. kaip ir minėjau, mano versija yra naujesnė nei 1.1 (bet senesnė nei 2.8), tačiau įkeltas senas css failas, kuriame ir matosi 1.1 versija. Seną css failą įkėliau, nes jį anksčiau (kai naudojau nelegalią 1.1 versiją) redagavau pagal savo poreikius ir nebenorėjau vėl perrašinėti pakeistų eilučių.
      Šiuo metu Džiugui baigėsi prenumerata, todėl negaliu gauti naujesnės legalios versijos. Jei tu turi elegant themes prenumeratą ar gali gauti naujesnę temą, bučiau dėkingas jei parašytum man į el. paštą: [email protected] 🙂

Parašykite komentarą

El. pašto adresas nebus skelbiamas. Būtini laukeliai pažymėti *