Nõrgast paroolist häkitud WordPressini 42 katsega
Vaatamata sellele, et iga turva-nõuanne hakkab pihta tugeva parooliga ja enamus kasutajaid sedaküsimise peale ka esimese meetmena nimetavad… on nõrga parooli kasutamine endiselt reaalne probleem.
Esimene samm: kasutajanimede kogumine
Seekordne näide põhineb ühe reaalse ründe logifailidel, alustuseks otsitakse WordPressi kasutajanimesid lapates läbi autorite arhiivi:
163.172.xxx.xxx [10/Dec/2018:20:39:22] "GET /?author=1 HTTP/1.1" 301 163.172.xxx.xxx [10/Dec/2018:20:39:22] "GET /?author=2 HTTP/1.1" 301 163.172.xxx.xxx [10/Dec/2018:20:39:22] "GET /?author=3 HTTP/1.1" 404
Kood 301 on edasisuunamine: kui proovida minna lehele https://www.zone.ee/blogi/?author=16, siis on selleks https://www.zone.ee/blogi/author/petskratt/ … ja minu kasutajanimi petskratt on selles kenasti näha.
Teine samm: parooli mõistatamine:
Kui kasutajanimi teada, võib hakata proovima sisselogimist:
163.172.xxx.xxx [10/Dec/2018:20:39:25 +0200] "POST /wp-login.php HTTP/1.1" 200
Selliseid ridu on logis 41 ning kõigi nende puhul on WordPress väljastanud teate, et parool ja/või kasutajanimi ei klapi.
Ma olen selliseid katseid kogunud ja tüüpiliselt on proovitavad mustrid kasutaja petskratt ja veebilehe zone puhul sellised:
petskratt2017 petskratt2018 P@ssw0rd petskratt1234 petskratt12345 petskratt@123456 12345678 petskratt@zone zone2018
Siia sobib kenasti Hasso postitus Veel kord paroolidest ehk kuidas aegunud parooli-nõuded on õpetanud kasutajad justnimelt selliseid lihtsalt ära-arvatavaid paroole kasutama.
Ja niimoodi nad siis huupi lappavad, kuni mõne veebi puhul mõne kasutajaga näkkab. Sedapuhku on juba 42. rida on veidi erinev:
163.172.xxx.xxx [10/Dec/2018:20:39:54 +0200] "POST /wp-login.php HTTP/1.1" 302
302 on jällegi edasi-suunamine ning selle sihiks on /wp-admin … Rohkem IP-aadress 163.172.xxx.xxx logis ei esine, sest töö sai tehtud. 32 sekundiga.
Mõni päev hiljem:
103.76.xxx.xxx [12/Dec/2018:06:06:07 +0200] "POST /wp-login.php HTTP/1.1" 302
Kui 163.172.xxx.xxx oli pärit Prantsusmaa internetiteenusepakkuja võrgust, siis 103.76.xxx.xxx külastab meid Indiast, Tamil Nadu osariigist. Kontrollib logini toimimist ja rohkem teda näha pole.
Kolmas samm: parooli ärakasutamine
Ilmselt läheb toimiv kasutajanimi+parool müüki ning uus omanik asub selle abil saiti lammutama:
46.148.xxx.xxx [17/Dec/2018:22:29:54 +0200] "POST /wp-login.php HTTP/1.1" 302 46.148.xxx.xxx [17/Dec/2018:22:29:54 +0200] "GET /wp-admin/ HTTP/1.1" 200 46.148.xxx.xxx [17/Dec/2018:22:39:29 +0200] "POST /wp-admin/update.php?action=upload-theme 46.148.xxx.xxx [17/Dec/2018:22:39:32 +0200] "GET /wp-content/themes/[...]/db.php?u 46.148.xxx.xxx [17/Dec/2018:23:00:32 +0200] "POST /wp-content/themes/[...]/db.php?u
Ehk siis login, oma teema üleslaadimine, selles oleva db.php tagaukse toimivuse kontroll ja ärakasutamine. Kui huvi, siis see näeb välja selline:
IP 46.148.xxx.xxx viitab Kiievile, aga kuulub sealsele veebimajutusteenusele ja kuigi tegemist võib olla ka VPNi või veebi-proksi kasutajaga viitavad mõned logiread skriptitud tegevusele, näiteks selle üleslaadimis-käsu puhul on logis referrer-väljal http://$st2/wp-admin/theme-install.php?browse=featured.
Mida sellise jama vältimiseks teha?
- ära kunagi kasuta lihtsat parooli – ei enda kontol ega kolleegile / kliendile konto tegemisel (isegi, kui on plaanis see hiljem ära muuta – tõenäoliselt ei muuda seda keegi)
- vaata üle veebirakenduse admin’i / halduri õigustes kasutajate nimekiri ja kustuta lahkunud töötajad / endised arendajad jms kasutajad, keda enam vaja ei ole (või pane nende rollik subscriber / lugeja)
Lisalugu: aga kelle parool lekkis?
Kuna selles veebis oli mitu haldurit, siis pakkus mulle suurt huvi konkreetse kasutaja tuvastamine. See ei pruugi alati võimalik olla, aga tasub vaatada wp_user_meta tabelis olevaid session_token kirjeid. Sedapuhku oli kasutaja 2 kohta kirjas järgnev:
a:2:{s:64:"bff45f4a[...]";a:4:{s:10:"expiration";i:1547071064;s:2:"ip";s:11:"77.72.xxx.xxx";s:2:"ua";s:124:"Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3198.0 Safari/537.36 OPR/49.0.2711.0";s:5:"login";i:1545861464;}s:64:"a3c7456[...]";a:4:{s:10:"expiration";i:1548253873;s:2:"ip";s:11:"91.90.xxx.xxx";s:2:"ua";s:124:"Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3198.0 Safari/537.36 OPR/49.0.2711.0";s:5:"login";i:1547044273;}}
Ülalpool näha oleva 46.148.xxx.xxx loginit ei ole enam näha (sest ta ei ole välja loginud? liiga ammu?), küll aga on näha 2 teist IPd, esimese asukohaks annab MaxMind Stoke-on-Trent’i ja teise omaks Odessa. Huvilised võivad tuvastada ka sisselogimise aja… ning logist on kenasti näha nende askeldamised 🙂
Populaarsed postitused
Nutikas Pilveserver: tark lahendus e-poe ja nõudlike veebiprojektide jaoks
Hallatud või halduseta platvorm: kumb vastab paremini sinu vajadustele?
Zone Veebiakadeemia - lihtsad tööriistad kodulehega alustamiseks
Kommentaarid
6 kommentaariSuper lugu! Ja kõige levinud user name zones on siiski ZonePluss kui keegi soovib zones majutatud veebilehte häkkida, kasutage seda.
True that 🙂
Aga vähemalt pannakse sellele turvaline parool ja ma olen suht kindel, et isegi kui kasutaja parooliks malleke1 paneb, ei ole see nii kergesti lammutatav kui kasutajanime malleke puhul.
Ja greppides 2017 detsembrist alates minu testveebidelt (10kond WPd) kogutud 10 mega bruteforce logi EI OLE seal ühtki zoneplus katset.
Ma olen Wp alal suht võhik, aga miks ei võiks näiteks peale 10. login katset sinna sissenõudmise lihtsalt lukustada? Ja avatakse peale identiteedi tuvastamist ja piisavalt alandlikku palvet?
Ütleme nii, et OWASP Application Security Verification Standard’i (https://www.owasp.org/images/6/67/OWASPApplicationSecurityVerificationStandard3.0.pdf) kohaselt iga ennast vähegi turvaliseks pidada tahtev võrgu kaudu kasutatav rakendus (ASVS Level 1 nõuded) mitte “võiks” või “peaks”, vaid “peab”:
“2.20 Verify that request throttling is in place to prevent automated attacks against common authentication attacks such as brute force attacks or denial of service attacks.”
Olgu seejuures mainitud, et “denial of service attacks” oleks mh see, kui keegi saab 10x proovides su konto lukku lasta… nagu juhtus ühe ministri e-postiga mõni aeg tagasi. Ehk siis oleks vajalik nt IP-põhine kontroll, samas ei ole ründajal suurem mure need 100 parooli proovimiseks vajalikku 100 IPd oma botnetti saada (loe: https://www.zone.ee/blogi/2017/06/27/paha-panda-varastab-postkaste/). Ehk asi on tiba keerulisem kui esmapilgul tundub.
WPs vaikimisi sellist funktsionaalsust pole (ilmselt selle sama keerukuse pärast), küll aga tuleb meie Zone+ kaudu installitud WordPressiga kaasa Limit Login Attempts Reloaded plugin mis piirab sisselogimiskatseid (seejuures selliseid, mis wp-login.php asemel kasutavad xmlrpc.php API-liidest).
Igal juhul – kasuta turvalist parooli. Põhiline on pikkus (12 tähemärki on juba väga ok), mitte-ära-arvatavus (et ei oleks seost kasutajanime, saidi või levinud parooliga) ja korduskasutuse vältimine (et kui ühest kohast parool lekib seda mujal pruukida ei saaks).
karunahaparkla ja lehmakommentaarium on väga head paroolid – ja ma olen päris kindel, et isegi https://twitter.com/keitivilms parimad kalamburismid pole veel ründesõnastikesse jõunud 🙂
Segane jutt. Kas zone koos artikli autoriga tunnistab hetkel turbe mõõdalaskmisi?
Ja kas vabatahtlikud võivad antud artikli näidete raami põhjal käed külge panna ning otsida turvavigu teenuse täiustamiseks?
Kui kasutaja paneb endale (või veebimeister paneb kasutajale) parooli stiilis kasutajanimi123 – siis otseloomulikult on see möödalaskmine. Ühelt poolt kasutaja/veebimeistri/ITspetsi käitumises (uskumatult suur tõenäosus on kohata ITspetsi, kes firmas kontot luues paneb parooli stiilis firma2019) ja teiselt poolt paroolireeglites, mis on aastaid kontrollinud suurtäht-väiketäht-number-märk vms reeglit, millest teadagi saab mööda Peeter1! nipiga. Reeglitest räägib mh https://www.zone.ee/blogi/2018/11/22/veel-kord-paroolidest/ Hasso blogipost.
Mida muuta? Uuematel WordPressidel genereeritakse turvalised paroolid, ise sisestades kuvatakse turvalisuse indikaatorit (vt https://github.com/dropbox/zxcvbn) ning ebaturvalise parooli lubamiseks on vaja vastav “linnuke” märkida… paraku see veeb oli aastatetagune. Samuti võiks kasutada nt https://wordpress.org/plugins/limit-login-attempts-reloaded/ pluginat, mis Zone+ abil WPd installides on juba vaikimisi aktiivne…
Igaüks saab võtta kasutusele nt https://lastpass.com/create-account.php paroolihalduri ning kasutada igas teenuses unikaalset keerulist (genereeritud) parooli.
Zone muutis paroolipoliitikat pärast https://www.zone.ee/blogi/2017/06/27/paha-panda-varastab-postkaste/ juhtumit – ka meil on nüüd kasutusel ZXCVBN mudel mis saab sisendiks mh kasutaja nime ja kasutajanime. Klientide WordPressid on aga klientide vastutusala – vt https://www.zone.ee/et/lepingud/infoturbe-pohimotted/ olevat “vastutuse pinude” pilti.
Kommentaarid suletud.