Nõrgast paroolist häkitud WordPressini 42 katsega

Peeter Marvet
Jaga:

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 🙂

Kommentaarid

6 kommentaari
  • Super 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?

Kommentaarid suletud.

Populaarsed postitused

Vähem peavalu uute PHP versioonidega

PHP 8.2 nüüd ametlikult väljas

Ingmar Aasoja
PHP versioon 8.2 on nüüd ametlikult väljas. Käesolevaga keskendume sellega kaasnevatele olulisematele uuendustele.

Partner soovitab:
Veebilehe optimeerimine paneb tulud kasvama

Digielu
Tänapäevase veebilehe optimeerimine mõjutab otseselt seda, kui hästi nii otsingumootorid kui ka kasutajad sinu veebilehte tajuvad.

Teeme andmebaasiühendused turvalisemaks

Ingmar Aasoja
Teatavasti on SQL andmebaaside kasutajatel vaikeseadistustes lubatud ühenduda ainult lokaalselt, mis tagab selle, et andmed ei liigu üle võõraste võrkude....