Svešu administratora kontu atrašana CMS un serverī

Īsi sakot: Svešus admin kontus atradīsit tikai tad, ja pārbaudīsit visus līmeņus: CMS vai veikalu, hostinga paneli, servera sistēmas lietotājus, SSH piekļuves un datubāzes lietotājus. Nepaļaujieties uz lietotāju sarakstu aizmugurē, jo ievadīts kods tur var slēpt kontus. Atradumus vispirms dokumentējiet un bloķējiet, tad noskaidrojiet cēloni un tikai pēc tam dzēsiet.

Kāpēc nezināms administrators ir tik bīstams

Papildu admin konts uzbrucējiem ir ērtākā slēptā piekļuve. Tai nav vajadzīgs ļaunprātīgs kods, tā neuzkrīt failu skenēšanā un pārdzīvo katru atjauninājumu. Kas vēlāk ar šo kontu piesakās, protokolā izskatās kā parasts redaktors.

Pēc PHP2Shell šī pārbaude iegūst svaru. Ievainojamības CVE-2026-109618 un CVE-2026-109619 ļauj izpildīt ļaunprātīgu kodu bez pieteikšanās. Kas serverī var izpildīt kodu, var arī rakstīt datubāzē un tādējādi izveidot kontus. PHP atjauninājums ievainojamību aizver, bet nenoņem kontu, kas radies iepriekš.

PHP2Shell nav publicētu, apstiprinātu Indicators of Compromise, tātad nav tipisku pēdu saraksta. Nezināms konts tāpēc nav PHP2Shell pierādījums, bet skaidra norāde uz neatļautu piekļuvi, neatkarīgi no ceļa. Pārskats par citām pazīmēm ir sadaļā Vai esmu jau kompromitēts?.

Kur var slēpties svešie admin konti

Daudzi operatori skatās tikai CMS. Uzbrucēji domā līmeņos, un katram līmenim ir savi konti:

SSH līmenis ir pietiekami patstāvīgs atsevišķam rakstam: Nezināmu SSH atslēgu atrašana un noņemšana.

Svešu admin kontu atrašana CMS, arī slēptos

Lietotāju sarakstu aizmugurē ģenerē pati lietojumprogramma. Ja līdzi darbojas ievadīts kods, tas var izfiltrēt atsevišķus ierakstus. Uzticamāki tāpēc ir rīki, kas skatās tieši uz saglabātajiem datiem. WordPress WP-CLI uzskaita visus administratorus ar izveides datumu:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Vēl dziļāk iet lasošs vaicājums datubāzē. Tas parāda katru kontu, kuram piešķirta administratora loma, neatkarīgi no tā, ko rāda saskarne. Tabulas prefiksu wp_ pielāgojiet savai instalācijai:

SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%administrator%'
ORDER BY u.user_registered DESC;

Salīdziniet rezultātus no aizmugures, WP-CLI un datubāzes. Ja konts parādās tikai datubāzē, tā ir spēcīga brīdinājuma pazīme, jo tad spēlē ir arī kods, kas to slēpj. Citām sistēmām, piemēram, Shopware, TYPO3 vai Joomla, ir spēkā tas pats princips: lietotāju tabulu vaicāt tieši un salīdzināt ar attēlojumu aizmugurē. Kuras tās ir tabulas, norādīts ražotāja dokumentācijā.

Sistēmas lietotāju un datubāzes lietotāju pārbaude

Pašā serverī galvenokārt interesē konti ar root tiesībām un konti, kas var pieteikties. Šīs komandas tikai lasa:

# Konti ar UID 0 (parasti tikai root)
awk -F: '$3 == 0 {print $1}' /etc/passwd

# Konti ar īstu pieteikšanās čaulu
grep -vE '(nologin|false)$' /etc/passwd

# Admin grupu dalībnieki
getent group sudo wheel

# Papildu sudo noteikumi
sudo ls -la /etc/sudoers.d/
sudo grep -rvE '^\s*(#|$)' /etc/sudoers /etc/sudoers.d/

# Pēdējās pieteikšanās ar pilnu datumu
last -F | head -30

Datubāzes serverī pārbaudiet, kādi lietotāji eksistē un kādas tiesības tiem ir:

SELECT user, host FROM mysql.user ORDER BY user;
SHOW GRANTS FOR 'anwendung'@'localhost';

Lietojumprogrammai parasti vajadzīgs lietotājs ar tiesībām tieši uz vienu datubāzi. Papildu lietotājs ar globālām tiesībām, kas drīkst piekļūt no jebkuriem hostiem (%), jānoskaidro.

Neaizmirstiet kontus ārpus servera. Kam ir piekļuve domēna līgumam vai DNS pārvaldībai, var novirzīt apmeklētājus vai ļaut izdot sertifikātus uz svešiem serveriem. Papildu īpašnieks Google Search Console var iesniegt vietņu kartes un mainīt iestatījumus. Tāpēc reģistratorā, DNS sniedzēja, CDN un Search Console pārskatiet pilnvaroto sarakstu un salīdziniet ar to, ko zina jūsu komanda.

Kā pareizi rīkoties ar atradumu

Pirmais impulss ir sveško kontu nekavējoties dzēst. Tomēr tad pazūd arī svarīga pēda: izveides datums bieži ierobežo, kad uzbrucējs bija sistēmā. Labāk ir šāda secība:

1. Dokumentēt: lietotājvārdu, ID, e-pastu, izveides datumu, lomu un pēdējo aktivitāti ar laiku nofiksēt, vislabāk kā ekrānuzņēmumu un eksportu.
2. Bloķēt, nevis dzēst: atņemt lomu, paroli aizstāt ar nejaušu vērtību vai kontu deaktivizēt.
3. Ierobežot laika posmu: pārbaudīt žurnālus ap izveides datumu. Kādi pieprasījumi bija īsi pirms tam, kuri faili mainījās?
4. Pārbaudīt citus līmeņus: kas izveido kontu, reti atstāj tikai vienu pēdu. Pārskatīt arī failus, cronjobs, SSH atslēgas un datubāzi.
5. Attīrīt un atjaunot piekļuves: tikai pēc attīrīšanas un PHP atjauninājuma atjaunot visas paroles, atslēgas un sesijas.

Piesardzības piezīme: ne katrs nezināms konts ir ļaunprātīgs. Aģentūras, agrākie pakalpojumu sniedzēji vai uzturēšanas spraudņi dažkārt izveido savus kontus. Noskaidrojiet to, pirms celat trauksmi, bet noskaidrojiet savlaicīgi.

Novērst atgriešanos

Pēc attīrīšanas admin kontiem jābūt izņēmumam, nevis normai. Labi darbojas personiski konti, nevis koplietotas piekļuves, pēc iespējas mazāk administratoru un divu faktoru autentifikācija admin piekļuvēm. Turklāt nosakiet, kas drīkst izveidot jaunus admin kontus un kur tas tiek dokumentēts.

Regulārs vaicājums, kāds iepriekš minētie, piemēram, ik nedēļu un ar salīdzinājumu ar iepriekšējo nedēļu, jaunus kontus padara ātri redzamus. WordPress gadījumā papildus palīdz ceļvedis Backdoor atrašana WordPress.

Kā PHP SOS palīdz konkrēti?

• Mēs pārbaudām visus kontu līmeņus no CMS caur serveri līdz datubāzei un salīdzinām aizmugures attēlojumu un saglabātos datus.
• Mēs nodrošinām atradumus ar laika zīmogiem, pirms konti tiek bloķēti vai noņemti.
• Incident Response ietvaros mēs noskaidrojam, kā konts radies un vai pastāv citas slēptās piekļuves.
• Mēs atjaunojam piekļuves pareizajā secībā un iestatām pastāvīgu jaunu admin kontu kontroli.

Biežāk uzdotie jautājumi

Avoti

• WordPress
• php.net: drošības paziņojumi
• BSI: norādes par IT drošības incidentiem