Před časem se na uživatele na naší univerzitě snesla vlna phishingových útoků. Při snaze o vyřešení tohoto problému jsme příliš úspěšní nebyli. Nejlepší obranou je vzdělávání uživatelů, ale to je bohužel málo účinné. Uživatelé se prostě chtějí zaměřovat na svou práci a na bezpečnost jim už tolik pozornosti nezbývá. Ale určitě je vzdělávání to nejdůležitější.
Útoky probíhaly podle velice podobného scénáře. Rozeslal se mail z nějaké adresy, ve kterém byl odkaz na podvržené webové stránky, kde se uživatelé přihlašují. Velmi často to byly Office365 od Microsoftu, ale setkali jsme se i s kopiemi našich vlastních stránek. Pak útočník jednoduše čekal, až se nějaký uživatel chytí. A chytil. Účet takového uživatele byl pak okamžitě použit k rozesílání dalších mailů, ale už s adresou reálného uživatele. A tak pokračoval útok dál a dál.
Účet postiženého uživatele jsme samozřejmě ihned zablokovali a nechali ho změnit heslo. Ale škoda byla už napáchána, spousta dalších měla již phishingový mail ve své schránce a je zcela nemožné je všechny odstranit. Tak mě napadlo, že bychom alespoň mohli zabránit tomu, aby se uživatelé na onen phishingový web dostali. Opět jsem využil RPZ filtr v rekurzivním DNS resolveru.
Vytváříme filtr
Na jednom z resolverů jsem vytvořil zónu phishing a aplikoval do policy. Druhý resolver si ji stahuje a aplikuje sám, podobně jako u odebírání filtru nocoin. Zablokovaná doména není hlášena jako neexistující ( NXDOMAIN), ale je přesměrována na informační stránku pro uživatele.
Zónový soubor:
$TTL 2h
$ORIGIN phishing.
@ IN SOA phishing. abuse.upce.cz (
2020010702
12h
15m
3w
2h
)
IN NS dns-cache.upce.cz.
IN NS eproxy2.upce.cz.
kontorshjalp100.moonfruit.com IN CNAME cms-proxy.upce.cz. ; 14.9.2018
uiire-fifa-hikaku.jp IN CNAME cms-proxy.upce.cz. ; 25.9.2018
otjeg35.webnode.com IN CNAME cms-proxy.upce.cz. ; 01.10.2018
Do zónového souboru si vkládám, jako poznámku, datum přidání záznamu. Útoky trvají většinou jen pár dní a není nutné mít ty záznamy příliš dlouho. Zóna je jen pro naše interní použití, nemusí tedy ctít pravidla top level a národních domén.
Pak jsem zónu aplikoval jako filtr na primárním resolveru:
response-policy {
zone "rpz.cesnet.cz";
zone "phishing";
zone "nocoin.upce.cz";
};
key "phishing" {
algorithm hmac-sha256;
secret "j....HDkA=";
};
server 78.128.211.132 { keys "phishing"; };
server 2001:718:1:1f:50:56ff:feee:132 { keys "phishing"; };
zone "phishing" {
type master;
file "/var/cache/bind/phishing.conf";
allow-transfer { 2001:718:1:1f:50:56ff:feee:132; 78.128.211.132; };
};
Sekundární resolver má stejnou konfiguraci, jen zóna není lokální a stahuje se:
zone "phishing" {
type slave;
masters { 2001:718:603:e195:113:124:0:33; 195.113.124.33; };
file "phishing";
};
Přenos zóny jsem zabezpečil pomocí TSIG. Tím, že je transfer zóny povolen jen na určitou adresu, Bind automaticky notifikuje sekundární resolver, aby provedl aktualizaci. Blokace je tak okamžitá na obou resolverech.
Informační stránka pro uživatele
Abychom naše uživatele informovali, že se je snaží někdo nachytat, vytvoříme si na nějakém serveru informační stránku. Nakonfigurujeme si webový server. Příklad uvádím jen pro Apache a port 80. Port 443 nakonfigurujeme stejně, i když tam je použití omezené tím, že název blokované domény nemáme v certifikátu. Ale zkušenost mě naučila, že když uživatel klikne na phishingový odkaz v mailu, odkliknutí nevalidního certifikátu ho nezastaví. Používání http a https je v mailech tak půl na půl.
<VirtualHost *:80>
ServerName cms-proxy.upce.cz
DocumentRoot /var/www/html
RewriteEngine On
RewriteCond %{HTTP_HOST} !^cms-proxy\.upce\.cz$
RewriteRule ^/(.*)$ /nophishing.html
CustomLog ${APACHE_LOG_DIR}/nophishing_access.log vhost_alias_combined "expr=!%{HTTP_HOST} -in {'cms-proxy.upce.cz','195.113.124.138'}"
CustomLog ${APACHE_LOG_DIR}/access.log vhost_combined "expr=%{HTTP_HOST} -in {'cms-proxy.upce.cz'}"
</VirtualHost>
Aby nám server odpovídal na všechny blokované domény, musíme tuto ukázanou konfiguraci provést ve výchozím virtuálu. Který to je? Ten, který má ServerName shodné s hostname stroje. Tam Apache hází všechny http dotazy na virtuály, které nemá explicitně nakonfigurované.
To, že pomocí DNS budeme posílat dotazy na svůj web, místo na původní, znamená jen, že se TCP spojení bude navazovat s naším serverem. V HTTP hlavičce ale zůstane dotaz na původní doménu.
Rewrite říka: pravidlo použij na všechny dotazy, které nejdou na http server cms-proxy.upce.cz. Na všechny dotazy, ať je v URL cokoliv, vracej soubor nophishing.html.
Nakonec si pomocí regulárního výrazu oddělíme logování. Vše co se týká phishingových dotazů se zapisuje do souboru nophishing_access_log, dotazy přímo na doménu cms-proxy.upce.cz zapisuje do standardního logu.
Praktické zkušenosti
Odkazy, které jsou vloženy přímo do mailu, nebývají často přímo tou doménou, kterou je třeba zablokovat. Rhybáři velmi často ovládají několik různých serverů a v rámci jednoho útoku používají mnoho různých domén. Ty často využijí jen pro přesměrování a všechny dotazy, z různých domén, tak končí na jednom jediném serveru. Proto než doménu zablokujete, zkontrolujte, zda jen nevede na několik různých přesměrování, blokujte až cílovou doménu. Ale proveďte to rychle, než si uživatelé stihnou mail přečíst.
Ukázalo se, že má smysl napsat správci serveru, který byl zneužit, správci to velmi často opraví. To, že je server zneužíván, není na první pohled pro dotčeného správce vidět. Hack je skryt, aby nenarušoval normální chod serveru a zůstal k dispozici po dlouhou dobu.
Jednou jsem dokonce byl schopen získat i kód té phishingové stránky. Útočník si na serveru nechal zazipovanou kopii. Přes velmi precizně zpracovanou vizuální stránku, byl vlastní PHP kód napsán velmi hrubě a nedbale. Stejně dělal jen to, že získané údaje posílal kamsi mailem.
Setkal jsem se také s phishingovým útokem, který nebyl cílen na nás. Byl psán dobrou češtinou, využíval náš vizuální styl, jména a funkce našich skutečných zaměstnanců k vyvolání zdání, že jej odesíláme my. Zkrátka profesionální práce. Účelem bylo šíření zavirované přílohy. Vyvolalo to vlnu dotazů a telefonátů, co to posíláme. Proti tomuto útoku se moc dělat nedá, ale můžete to zkusit. Rozhodně se ten mail pokuste získat a především jeho hlavičku.
Z logu poštovního serveru můžete získat jen adresu odesílatele (v našem případě to byl jeden americký webhosting). Ale hlavička mailu nám prozradila mail agenta, který mail vytvořil a zemi původu. Kontaktovali jsme hosting, ti nám vyšli vstříc a díky znalosti mail agenta identifikovali původce. No a země původu? Mail šel přes australskou univerzitu, tichomořské ostrovy a Gruzii z Moskvy.
ČLÁNKY DO MAILU