Myrtus Projekt

 

A Stuxnet-et spekulációk és legendák lengik körül, a valós hatásmechanizmusát csak kevesen ismerik, így az érdeklődő a magyar nyelvű internetes oldalakon jószerivel csak találgatásokkal és feltevésekkel találkozhat. A Google-be bepötyögve a „Stuxnet” keresőszót, nagyjából 3 millió találatot ad, a keresési feltételeket a magyar nyelvre szűkítve még mindig marad 30 ezer találat. A megjelent cikkek jobb esetben általánosan fogalmaznak a vírussal kapcsolatban, rosszabb esetben pedig pontatlan vagy hamis tényeket közölnek.

 Ebben a cikkben a Stuxnet pontos hatásmechanizmusát szeretném feltárni, de még mielőtt elmerülnénk a laikusok számára értelmetlen részletekben, megkísérelem összefoglalni a vírus történetét – itt viszont sajnos én is csak találgatásokra tudok hagyatkozni. Aki ezen a területen több információval rendelkezik, kérem, saját érdekében hallgasson ezekről!

 Ennek a dokumentumnak a megírásához sok, sokszor csak találgatásokba menő forrást használtam fel. Megpróbálok ezek között súlyozni, és saját, 15 éves ipari programozói rutinomra támaszkodva egy objektivitásra törekvő, de alapvetően szubjektív írást összelapátolni.

 Több cikkben is kifejtik, hogy a Stuxnet nem vírus, hanem a pontos metodika szerint féreg (worm) és/vagy rejtőzködő (rootkit). Ennek ellenére a Stuxnet, kártevő és vírus szavakat rokon értelmű szavakként kezelem a cikkben, így kevesebb lesz talán a szóismétlés.

A háttér (elsősorban laikusoknak)

 

Az ipari rendszerek irányítását világszerte speciális cél-számítógépekkel, az un. PLC-kel (Programable Logic controller, németül: SPS - Speicherprogrammierbare Steuerung) végzik. Ezeken a kontrollereken speciális nyelvű program fut. A program működésébe természetesen időnként be kell avatkozni, illetve azt sem árt tudni, hogy éppen mit művel a rendszerünk, erre a célra az un. HMI-k (human-machine interface) szolgálnak. Ha összetettebb feladatokat is szeretnénk a terminálokon végeztetni, mint mondjuk adat-archiválás, osztott irányítás, idődiagram-kezelés, akkor SCADA-t (Supervisory Control And Data Acquisition) vetünk be erre a célra. A SCADA-k olyan program-rendszerek, melyek többnyire valamely Windows operációs rendszeren futnak, és szerveren vagy szervereken keresztül csatlakoznak a PLC-khez. A lenti képen egy ilyen rendszer látható – ezt nem a cikk céljából rajzoltam, és ez látszik is rajta. A vállalatirányítási szisztémák természetesen több rendszert is tartalmaznak, de most csak a SCADA-t és a PLC-t vegyük a nagyítónk alá, a későbbiekben ugyanis róluk fog szólni ez a történet.

 

Sokszor, amikor az ilyen rendszerekről beszélgetünk a megbízókkal, felmerül a kérdés, hogy a Windows alkalmazása mennyire teszi sérülékennyé ezeket a technológiákat, és bizalomgerjesztő választ sajnos nem tudok adni: „Nagyon”. A Windowsra számolatlanul fejlesztik a vírusokat elvetemült krekkerek, és a vírusirtó technológia mindig csak lekövetni tudja ezeket a károkozókat.

Krekker: (angolul cracker) Míg a hackerek a rendszerbehatolásaikat és –töréseiket a későbbiekben publikálják és nem élnek vissza ezekkel az információkkal (etikus hacking), addig a krekkerek a sötét oldal képviselői. A töréseket, vírusokat, backdoor-okat adatszerzésre, zsarolásra és károkozásra használják fel. A krekking egyik minősített esete a Stuxnet léte.

- Akkor még mindig ott van a SCADA, mely védettebb lehet a vírusoktól – érkezhet a következő, reménykereső kérdés, de a válasz ismét elkeserítő: Nemhogy védettebbek lennének ezek, mint a többi program, hanem éppen ellenkezőleg. A gyári jelszók szinte minden esetben alkalmazhatók belépéshez, több a SCADA-kra épülő termék ezeknek az „alap” jelszavaknak a megváltoztatását sem engedi meg (Nem akarok konkrét nevekkel tippeket adni) – bár a szakmában mindenki tudja, mire gondolok.

 A SCADA-kból ráadásul nincs túl nagy választék a piacon, a nagyok (Inellution Fix, Intouch, WinCC) a piac nagy részét lefedik. Ezek gyenge pontjainak a feltárása – meg merem kockáztatni – nem nagy kaland, szakmabeliek bármelyik hibáiból kisebb litániát dobnak össze a munka utáni sörözéskor. 

 Amennyiben a SCADA jelszavakkal rendelkezik a kártevő, onnan bármely adatokat ki tud olvasni, és internetes kapcsolat esetén ezeket továbbítani tudja megírója felé, aki kielemezheti a technológia működését – és ez még csak a kisebbik baj. Nagyobb gond az – mint a Stuxnet története is rávilágít erre – a behatoló a SCADA és azon keresztül a PLC-k működését is befolyásolni tudja, illetve a PLC-k felől érkező hamis információkat tud megjeleníteni a kijelzőkön, megtévesztve ezzel a kezelőszemélyzetet.

 A PLC-k a vírusok számára közvetlenül nem érhetők el, mert nem fut rajtuk operációs rendszer, vagy olyan program, ami fertőzhető lenne, csak egy lefordított célprogram, ami ciklikusan hajtódik végre.

 A programokat egy ún. programozói állomáson – ez egy Windows-os PC vagy laptop, Simatic fejlesztői környezettel – lehet fejleszteni, és innen lehet letölteni a PLC-kre. Ez az egész folyamat Achilles-sarka, ugyanis egy fertőzött géppel a PLC programokat felül lehet írni.

 A PLC-ken a Stuxnet a valós adatok helyett hamisított információkat továbbított a SCADA felé, miközben apránként tönkretette a PLC-k által felügyelt urániumdúsító centrifugákat és ez alatt az idő alatt a termelést is „szabotálta”.

Sztori

 

A kártevő 2010. júniusában „bukott le” a fehérorosz  „VirusBlokAda” cég által Iránban, a Bushehr erőmű egyik gépén, és azóta bebizonyosodott, hogy több, mint 100.000 számítógépet fertőzött meg, a Simatic WinCC SCADA-kat keresve. Csak Iránban 45.000 felügyeleti számítógép és szerver tartalmazta a vírust (Info: Homeland Security Newswire, 2011. február).

A felfedezés óta bebizonyosodott, hogy a Stuxnet vírus az erőműre közvetlen fenyegetést nem jelentett, mert annak az urániumdúsító berendezések voltak a célpontjai. Közvetett értelemben azonban az a tény mindenképpen fenyegető, hogy egy vírus bejutott a létesítménybe.

 A Stuxnet-et feltételezések szerint az USA-ban vagy/és Izraelben fejlesztették ki (több találgatásban is felmerült az izraeli hadsereg high tech különítményének, a Unit8200-nak a neve). Erre utal (de akár figyelem-elterelés is lehet), hogy a kód az alábbi hivatkozást tartalmazza: 1979 május 9; ezen a napon végezték ki a prominens zsidó üzletembert, Habib Elghanian-t Iránban, Izraelnek való kémkedés vádjával.

 Több feltevés szerint az izraeli Dimonában egy tesztkörnyezetet építettek ki Simatic rendszerrel és IR-1 centrifugákkal, és itt fejlesztették ki a Stuxnet támadó blokkját. A munkához az amerikai Idaho National Laboratory (INL) szakemberei adtak tanácsokat (vagy akár részt is vettek a fejlesztésben).

Az iráni urándúsító centrifugák kifejeszése a pakisztáni Abdul Qadeer Khan nevéhez köthető, aki a holland Urenco-nál is dolgozott, majd a cég által kifejlesztett berendezéseket “másodhasznosította” a pakisztáni atomfegyver-programban, és az általa “honosított” berendezéseket Pak-1 vagy P-1 néven fejlesztették és terjesztették a Közel-Keleten, többek között Líbiában és Iránban.

 

Természetes környezetben az uránérc 99,3 % 238U –ból és 0,7 % 235U uránium izotópokból áll össze. Mindenféle maghasadásos nukleáris tevékenységhez természetesen a ritkább 235-ösre van szükség, ennek kiválasztására több technológia is ismert, például a hőmérséklet diffúzió, a gázdiffúzió, légáramoltatásos leválasztás, elektromágneses-, lézeres- vagy plazma-szeparáció, Zippe- vagy a gáz-centrifugázás. 

 

 

Gázcentrifugázás: két uránizotóp tömege alig (mindössze három neutrontömegnyivel) különbözik egymástól. Az szobahőmérsékleten szilárd uránt melegítve és adalékolva gáz halmazállapotú vegyületté (urán-hexafluoriddá, UF6) alakítják át, s a két izotópot többnyire gázcentrifugákkal választják szét. Az izotópokból álló keverékből a nehezebb izotóp a centrifuga palástja mentén, a valamelyest könnyebb pedig a tengelyhez közelebb halmozódik fel. Így a palástról elvezetett keverék 238-as izotópban dúsabb, míg a tengely közeléből kiáramló gáz 235-ösban gazdagabb.

A dúsítást – az elérendő koncentrációtól függően – több, egymás mellett elhelyezett, sorba kötött centrifugával végzik. Egy-egy urándúsító üzem akár több ezer centrifugából állhat. A berendezések kerületi sebessége a 600 m/s-os sebességet is elérheti.

Az urándúsító centrifugákat is hajtó motorok nagyfrekvenciás átalakítóinak a technikai adatait azoknak a gyártóitól, a finn Vacon-tól és az iráni Fararo Paya-tól szerezték meg. Ez az “adatszerzés” még a szakértőket is meglepte, hiszen a Fararo Paya-t olyan szinten próbálták elrejteni az iráni hatóságok, hogy az IAEA (International Atomic Energy Agency: Nemzetközi Atomenergia-ügynökség) se tudott róla.

A fejlesztésbe rendkívül sok energiát és időt öltek, erre utal a kártevő komplexitása és fejlett hatásmechanizmusa, így szinte kizárt a magányos krekker teóriája, aki otthon, hobbiból fejlesztette volna a kódot. Itt egy komoly szakértőkből álló team-nek kellett állnia a háttérben, a fertőzés jól irányzott volta, és az, hogy a kártevő elérte a célját, profi kivitelezőket és bőséges finanszírozást feltételez.  

A fejlesztés a "Myrtus" projekt keretein belül történt, erre utal a beforgatott kód path-je: \myrtus\src\objfre_w2k_x86\i386\guava.pdb.

A "Myrtus" lehet egy hivatkozás a bibliai Eszterre, aki megmentette a perzsáktól az ókori zsidó államot, de lehet akár a “My RTU”s (remote terminal unit – távoli elérésű terminál) is.

A kódban található egy elgépelt hivatkozás is (ez akár a fejlesztőkre is utalhat, mert egy anyanyelvi angol nem vét ilyen hibát): A hivatkozás eredetije a DEADFOOT, ez a pilóták szlengjében a hajtómű-meghibásodást jelenti, és ezt sikerült DEAD007-nek gépelni a kódban (a kódoló a két „o” betüt 0-nak, a „T”-t pedig 7-esnek nézte). James Bond után szabadon, "rázva, nem keverve".

A fejlesztéshez kiindulásként valószínűleg, egy korábbi kártevő, a Conficker kódját használták. A féreg tevékenységéről egy maláj és egy dán szerverre folyamatosan jelentéseket küldött (www.mypremierfutbol.com, www.todaysfutbom.com), majd a nantanz-i támadás után ezeket a szervereket lekapcsolták üzemeltetőik.

Eredmény

2010. november 16.-án Irán leállította az urándúsítóit, miután a centrifugák több, mint 20%-a megsemmisült a Stuxnet tevékenysége nyomán, azaz a kártevő elérte az egyik célját.

A kártevő – persze megint csak feltételezések szerint – az igazi pusztítást a natanz-i urándúsító létesítményben fejtette ki, itt jó eséllyel kb. ezer IR-1 típusú urándúsító centrifugát égetett le. Ezeknek a berendezéseknek a hajtómotorja 1007 cps-nél (cycles per second, másodpercenkénti fordulatszám) is már tönkremegy, a Stuxnet viszont rövidebb fázisokra, észrevétlenül 1064 cps-es tempót diktált nekik, széthajtva őket.

Főnöki szemle a nantanzi urániumdúsítóban - a kép  Mahmoud Ahmadinejad 2008-as látogatásakor készült. Háttérben az ominózus centrifugák, fotó: Getty Images.

Nantanz városa körülbelül 225 kilométerre, délkeletre található Teherántól, oázisai híresek az itt termelt körtéről, mellyel egész Iránt innen látják el. Nem túl pc poén, de ide kívánkozik: lehet, hogy hamarosan világítani is fognak, ugyanis itt található a legnagyobb urándúsító telep is.

A mindösszesen 100.000 m alapterületű csarnokokat légvédelmi okokból 8 méterrel a föld alá telepítették, majd a későbbiekben – az izraeli haditechnika fejlődésével szinkronban - még több földet hordtak rá.

2009-ben a berendezés 8000 centrifugájából 5000 működött, és egy újabb telep létesítésébe fogtak Qom közelében. A pakisztáni P-1-es centrifuga iráni változának a kódneve az IR-1, és ennek a továbbfejlesztett változatai rendre IR-2, IR-3,.. névre hallgatnak.

Egy centrifugában viszonylag kis mértékű dúsítás érhető el, ezért ezeket úgynevezett kaszkádokba szervezik. A kaszkádokban a dúsított HF6 egyik irányban való áramoltatásával szemben a csökkentett 235U koncentrációjú HF6 a másik irányban mozog. A kaszkádok párhozamos kötésekkel is rendelkeznek. Feltételezések szerint a centrifugákat 164 elemű, 15 fokozatú kaszkádokba szervezték.

 Szintén Iránból származó – így meg nem erősített hírek szerint – a natanz-i urándúsító létesítmény igazgatóját eltávolították, több – először csak felfüggesztett – tudóst kémkedéssel vádoltak meg, illetve néhányan eltűntek közülük.

Habár az iráni hatóságok állítják, hogy a fertőzést megszüntették, minden szakértő tudja, hogy mindaddig, míg az alkalmazott technológiát nem cserélik le, az újabb – a Stuxnethez hasonló felépítésű, de eltérő működésű behatoló fertőzése csak idő kérdése. A Bushehr atomerőmű kapcsán emlegetett Csernobil-analógia bár nem következhet be (alapvetően a csernobili berendezés és az ott történtek nem vethetők össze az iráni erőművel), de – és ezt a Stuxnet fényesen bizonyította – ezek a  programok iszonyú károkat okozhatnak.  

 

Hatásmechanizmus

 

„Ez a legkomplexebb malware, melyet az utóbbi öt vagy több évben láttam” mondta Nicolas Falliere, a Symantec kódfejtője. “Ez az első ismert eset, amikor egy kártevő nem a hitelkártya információkat és nem a személyes adatokat akarja megszerezni, hanem technológiai rendszert támad. Ez egy egyedülálló és nem túl felvillanyozó tény.”

 A kód visszafejtése meglehetősen sok időt vett igénybe, mivel komplexitása mellett a mérete – fél Mbyte – is meglehetősen nagy.

 A teljes hatásmechanizmust két alfejezetre bontom:

 A “terjedés” fejezetben a károkozó terjedését kívánom ismertetni, mely még nevezhető “hagyományos” metódusnak, és a legtöbb fertőzött gépen a Stuxnet tevékenysége ezzel le is zárul (amennyiben nem találja meg a WinCC-t ott).

A “pusztítás” fejezetben a PLC-ken kiváltott hatását írom le a vírusnak.

Terjedés

 

A vírus terjedését fejlesztői nem bízták a véletlenre, rögtön három, “nulladik napi támadás”-t (Zero-Day Vulnerability) is indít a rendszer ellen.

Nulladik napi támadás (zero-day vagy zero-hour támadás) - Wikipedia:  egy biztonsági fenyegetés, ami valamely számítógépes alkalmazás olyan sebezhetőségét használja ki, ami még nem került publikálásra, a szoftver fejlesztője nem tud róla, vagy nem érhető még el azt foltozó biztonsági javítás. Zero-day exploitnak nevezik azt a tényleges kódot, amit a támadók használnak a sérülékenység kiaknázására, mielőtt a szoftver fejlesztője tudna arról.

 Bővebben a lásd a Wikipedia szócikkét: http://hu.wikipedia.org/wiki/Nulladik_napi_t%C3%A1mad%C3%A1s

 

 

“A” verzió: LNK Exploit

 Az „autorun” eszközök helyett a malware egy, a Windows parancsikonokat feldolgozó kódjában levő sebezhetőséget használ ki.

 Amint felhasználó a fertőzött USB meghajtót megnyitja az Windows Explorer-ben vagy egyéb más fájlkezelőben, amely képes ikonok megjelenítésére (például Windows Explorer), a rosszindulatú kód automatikusan végrehajtódik minden további felhasználói interakció nélkül. Mivel a StuxNet leginkább az USB-ken terjed, ezért klasszikus besorolás szerint ez a malware egy „féreg” (worm).

 A Microsoft biztonsági közleménye:

http://www.microsoft.com/hun/technet/security/bulletin/MS10-046.mspx

Exploit – Wikipedia: (ang.: kihasználás, kiaknázás) informatikai biztonsági fogalom: olyan forráskódban terjesztett vagy bináris program, adathalmaz vagy parancssorozat, amely alkalmas egy szoftver vagy hardver biztonsági résének, illetve hibájának kihasználására, így érve el a rendszer tervezője által nem várt viselkedést. Ez alatt a nem várt viselkedés gyakran a rendszergazdai jogok megszerzését, jogosultságnövelést (privilege escalation) vagy szolgáltatásmegtagadást (denial of service-t) értünk.

 Bővebben a lásd a Wikipedia szócikkét: http://hu.wikipedia.org/wiki/Exploit

“B” verzió: PRC Exploit

Az exploit véletlenszerűen megnyit egy portot 1024 és 10000 között, és itt web szerverként viselkedik. Véletlenszerűen próbál gépeket fertőzni a hálózaton, és ha ez összejön, HTTP-n keresztül másolja magát a nyitott porton. Másolás közben előszeretettel használja a .JPG kiterjesztést, majd véletlenszerű névvel .dll-ként menti magát a gépen.

“C” verzió: Spool Server Exploit

 Xp-s, osztott nyomtató szervereken minden további nélkül tud terjedni ez az exploit, a többi Windows termékeken csak bizonyos körülmények között.

 Ezt a rést elsősorban a Stuxnet használja ki. Induláskor számba veszi az összes hálózati nyomtató szervert, és megkísérel „Guest”-ként ezekhez csatlakozni. Amennyiben ez sikerül, másolja és futtatja magát.

Futtatás

A Stuxnet először egy backdoor funkciót aktivál (Worm:Win32/Stuxnet.A) a sérült rendszeren, majd két - rootkit funkciókkal ellátott - drivert telepít fel (mrxcls.sys, mrxnet.sys).

A driver-ek a Realtek Semiconductor Corp érvényes aláírásával rendelkeztek kezdetekben. Ez arra utalhat, hogy a malware szerzője valahogyan hozzáfért a Realtek privát kulcsához. A hírek szerint a Verisign azonban a a felfedezést követő hétvégén visszavonta a Realtek érintett certificate-jét.

 A két driver:

 - WinNT/Stuxnet.A trójai (trojan): elrejti a  .lnk fájlokat

 - WinNT/Stuxnet.B trójai (trojan): titosított adatsorokat tölt a memóriába, melyek által kiváltott funkciókat a következő al-fejezetben („pusztítás”) ismertetek.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

A képek forrása: Microsoft Malware Protection Center

A vírus terjedéséhez egy adalék, hogy – mint a felső ábrán az jól látható – igen célirányosan indult világgá. Bár - számomra – Indonézia kissé kakukktojás, de a másik két listavezető atomprogramjai igencsak ellenérzéseket indukálnak amerikai és izraeli kormánykörökben is.

Pusztítás 

A s7otbxdx.dll fájl a  „SIMATIC Device Operating System”  egyik eleme, ezt írja felül a Win32/Stuxnet.A. A DLL a fertőzés után három 64-bites titkosított fájlt fog tartalmazni, melyek adott kiváltó események hatására kikódolásra és letöltésre kerülnek.

 A Simatic S7 PLC-kről egy rövidebb összefoglalást itt talál.

 A kódok közül kettőt az S7-315-ösöknek és egyet az S7-417-eseknek szántak a fejlesztők. A 300-as sorozatú 315-ösöket kisebb berendezések irányításához szokás használni, míg a 400-as sorozatú 417-t (mondjuk 417-4H) jellemzően már jóval komolyabb (“H”-s, “F”-es vagy “FH”-s  - redundáns és/vagy hibatűrő) rendszerekhez szokás használni. A két 315-és kód szerkezetében hasonló és csak néhány kisebb eltérés található bennük.

 Mindhárom kód alátámasztja, hogy írói rendkívül célirányosan fejlesztették ezeket, a célhardver felépítésével és működésével tisztában voltak – a támadást sebészi pontossággal tervezték és hajtatták végre a vírussal.

DeadF007

 A 315-ös program hozzávetőleg 3000 sor hosszú Step7 AWL kódot és négy kisebb adatblokkot (DB 888...891) tartalmaz.  A programkód két FC-t (FC 1865 és FC 1874) generál és ezeket az OB1-be és OB35-be beágyazza.

A kód öt szakaszt futtat, ebből a leghosszabb a károkozások közötti kivárás, ez  13-90 bap lehet. A legrövidebb a „pusztítási” szakasz, amikor a korábban már megemlített Deadfoot (vagy DeadF007) feltételek összejönnek (ezeket az alkalmazott módból, a felügyelet jellegéből és a kivárási időből rakja össze a vírus).

A Deadfoot feltételek fennállása mellett – akár 50 perc hosszan is – a PLC eredeti funkcionalitását a vírus egy BEC-cel (conditional block end: feltételes blokk-lezárás) felfüggeszti, és a centrifugák sebességét először 1410 Hz-re viszi fel, majd 2 Hz-re csökkenti. Ezzel egyrészt a rotort teszi idővel tönkre, illetve az addig szeparálódott HF6-ot keveri össze. A program a rejtőzködésre játszik, a ritkán és véletlenszerűen végrehajtott szabotázsakció hosszú ideig nem észlelhető, főleg, hogy a SCADA rendszer ebből gyakorlatilag semmit nem észlel. A támadott aktuátorra a kimenő paramétereket a program a fixen rögzített DB 888-ból olvassa.

Fontos része a kódnak – mely a fejlesztők ismereteiről sokat elárul – a DP_RECV (Standard Library/ FC2) funkció működésének módosítása. Normál körülmények között ez a funkció – DP Slave oldalon – átveszi a DP-Master által továbbított kimeneti állapotokat a megadott DP területen.

A 417-esre szánt program kissé összetettebb a maga 12.000 soros AWL-jével, és tíz adatblokkjával. Két adatblokk (DB8062, DB8063) statikusként kerül letöltésre, egy dinamikusként (DB8061), a többieket pedig a kód generálja ki (DB8064..DB8070). Kifejezetten érdekes ezek közül a statikus DB8063, melynek mérete 26,790 byte, és egy 16 kbyte-os, 164 * 6-os  tömböt tartalmaz. A kigenerált kód az OB1-ből meghívásra kerülő FC-kből áll.

Szakértők eleinte úgy vélték, hogy ez a blokk a Bushehr elleni támadást hajtotta volna végre, de Ralph Langner vírusbiztonsági szakértő szerint ennek a 315-ös PLC-k fölötti S7-400-as „megbolondítása” volt a célja.

Míg az S7-300-asok egyértelműen a rotorokat és az egyedi centrifugák vezénylését végezték, szerinte a 400-as a technológiát és annak szelepeit felügyelte. A fent említett tömb jó eséllyel a szelepek funkcióinak a felülírását végezte, erre utal annak 164 * 6 –os tagolása. Ezt a DB-t (DB8063) például a – szintén generált – FC6068 hívta egy 168-as ciklusban, melyet viszont az FC6070 hívott fel hatszor. 

Valószínűleg a nantanzi centrifugák 6 darab 164 elemű kaszkádba voltak rendezve, így a vírus ennek a 984 centrifugának a fokozatos tönkretételét valósította meg.

A cikk itt folytatódik.

A cikk az ob121.com oldalon.

A bejegyzés trackback címe:

http://ob121.blog.hu/api/trackback/id/tr202660601

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben.