bardóczi ákos @post.r

Avagy létezik-e biztonságos letöltés? Főleg, ha nehezen beszerezhető anyagokról van szó.

Napjainkban a torrent szolgáltatásokban alap szinten jártas felhasználó csak annyit lát, hogy ha kell neki egy film, egyszerűen felmegy egy nagyobb torrentoldalra, majd rákeres a film címére, ezt követően pedig letölti a filmet kedvenc torrent kliensével.

A némileg tájékozottabb felhasználó már tisztában van vele, hogy vannak olyan peer-to-peer oldalak, amik valamilyen saját torrentkliens telepítését teszik annak feltételévé, hogy tőlük lehessen letölteni, ami persze felveti annak a lehetőségét is, hogy a torrentkliens nem csak letölteni illetve visszatölteni fog, hanem csinál valami teljesen mást is a gépen, mint mondjuk tolja a felhasználó arcába a reklámot. Ráadásul nagyon sok fertőző oldalra mutató hivatkozás a Google TOP 10-jében van.

Inkább a leggyakoribb tüneteket írom le, amit a torrent klienssel együtt települő malware csinálhat

- folyamatosan tolja a reklámod az arcodba, ha tetszik, ha nem
- a böngészők kezdőoldalát átállítja valami számodra érdektelen oldallá, amit nem tudsz visszaállítani
- a te géped szabad erőforrásait fogja a tudtod nélkül bitcoin bányászatra használni akkor is, ha nem is tudsz róla, a géped nincs üresjáratban, te pedig nem érted, hogy miért lassult be a gép
- mindenféle hülye eszköztárakat helyez el a böngészőben, amik szintén leirthatatlanok
- gyakorlatilag bármi más, ami az előzőekből kimaradt, de legalább ennyire idegesítő

Persze ezeket a malware vagy malware-szerű aktivitásokat vagy kiszúrja az antivírus szoftver vagy sem, ha ki is szúrja, könnyen lehet, hogy ha a kártékony programot sikerül eltávolítani, maga a torrent kliens sem lesz működőképes. Ráadásul akármilyen überszuper a vírusirtó, az intelligens malware gondoskodik róla, hogy szépen újratelepítse magát, méghozzá, hogy ne legyen feltűnő, nem is azonnal, hanem egy kis lappangási idő után.

Valóban vannak helyzetek, amikor már annyira romos egy gép, hogy újratelepíteni az egészet időtakarékosság szempontjából praktikusabb, mint kigyomlálni mindent, ami nem oda való, abban az esetben, ha a baj nem akkora - vagy nem tűnik olyan nagynak - nincs mese, riasztani kell valami harceddzettebb ismerőst, aki aztán alighanem állhat neki fúrni-faragni a Windows rendszerleíró adatbázisát,  könyékig túrni a böngésző, menüből nem elérhető finombeállításai közt, na meg guglizni, hogy egy-egy azonosított kártevőt hogyan lehet leggyorsabban leirtani kézileg - az egyetlen szerencse, hogy ez utóbbi már eléggé gyorsan elérhető. Azért írtam, hogy kézileg, mert olyan malware sem ritka, amelyik malware-eltávolítónak álcázza magát, azaz vírusgyilkolásra nem biztos, hogy a legjobb ötlet telepíteni még valamit, amit a kereső előkelő helyen dob és azt ígéri magáról, hogy eltávolítja, valójában pedig önmaga is vírus. OSX-es esetben pedig még cifrábbak lehetnek a protokollok és bizony ott is vannak nagyon komoly sebezhetőségek, ahogy az a The Register mai cikkéből is kiderül.

A windowsosos után pedig a legnagyobb kockázatnak pedig az elterjedtebb linux-disztrók használók közül az egyszerűbb lelkek vannak kitéve, akik még mindig úgy gondolják, hogy "jinyukszra nyinycsen víjus", ami igazából sosem volt igaz, de bízzunk benne, hogy majd felnőnek egyszer. A vírus és malware fogalmakat ugye rokonértelműként használom, ezek közül az egyik csoportba tartoznak a rootkitek, amik olyan rosszindulatú, kifinomult malware-ek, amik észrevétlenül és sokszor szinte észrevehetetlenül az operációs rendszer - akár legelemibb - működését változtatják meg, gyakorlatilag bárhogy. Linuxos rendszereken aztán végképp nincs semmiféle általános forgatókönyv rootkitek azonosítására, egy ősrégi módszer lényege, hogy a különösen fontos fájlok integritását, változásait folyamatosan figyelve van rá esély, hogy a rootkitet sikerül időben megfogni, kísérleti szinten sincsenek olyan módszerek, amik már a windowsos rendszereknél általánosan elterjedt ún. viselkedés-alapú heurisztikákat használnak, azaz azt szúrják ki, ha valami nagyon szokatlan történik, a témával kapcsolatban bővebben a poszt alján megjelölt könyvekből lehet tájékozódni.

Könnyen előfordulhat, hogy olyan tartalomra lenne szükségünk, ami eléggé specifikus ahhoz, hogy ne legyen fenn még a nagyobb torrent oldalakon sem, így jobban alá kell merülni a netnek.

Ha könyvet keresünk, ami nem teljesen újonnan jelent meg, lehet, hogy elegendő, ha a Google keresőjébe egyszerűen beírjuk a könyv címét a filetype:pdf operátorral, ami arra utasítja a keresőt, hogy csak a PDF-típusú fájlokat adja ki találatként és szerencsés esetben ott is lesz a teljes letölthető könyv, kevésbé szerencsés esetben pedig csak egy olyan oldalra jutunk PDF-csali miatt, ahol valójában a könyvnek csupán néhány oldala szerepel, a teljes könyv letöltéséhez már meg kellene adni a bankkártyaszámunkat, amivel kapcsolatban amúgy az adott webhely esküdözik, hogy nem von le róla egy garast sem, csak a felhasználó azonosítása vagy a free trial regisztráció megkezdése miatt kell :) És végig ne felejtsük el, hogy ha nem lennének olyan felhasználók tömegesen, akik még ezt is beszopják, nyilván nem érné meg üzemeltetni az ilyen oldalakat.

Nos, mi van akkor, ha kellene egy bizonyos könyv például, de az sehogy se sikerül normálisan lecibálni a netről, így az elszánt felhasználó nyel egy nagyot, kockáztat és megpróbálja minden áron lecibálni a tartalmat, a kockázatok minimalizálásával?

Kézenfekvőnek tűnik egy olyan gépet használni, amit akkor sem sajnálunk, ha rommá megy a rendszer rajta a nap végére, nemde? Végülis igen, de már igen korán felmerült rá az igény, hogy ehhez ne kelljen egy tényleges számítógépet és éles operációs rendszert használni, többek közt ez volt az egyik, aminek kielégítésére kifejlesztették az ún. virtuális gépeket. Ezek olyan szoftverek, amik a valódi operációs rendszer hátán alkalmazásként futva képesek más operációs rendszereket futtatni, amik gyakorlatilag teljesen izolált környezetben vannak, így a VM-ben futó operációs rendszer és annak alkalmazásai számára úgy tűnik, mintha valódi számítógépen futnának. Azaz ha valaki elkezd számítógépes vírusokkal foglalkozni, akkor egyszerűen ezekre az izoláltan, sandboxban futó operációs rendszerekre felteszi a vírusboncoláshoz szükséges eszközöket, na meg leferzőzi a vizsgálni kívánt vírussal. Hogy víruskutatókra nem kis szükség lesz, nem kérdés és a Duqu 2-be még bele se mentem.

Nos, a virtuális gépben futó operációs rendszereken szinte minden futtatható, amit az adott operációs rendszer támogat, persze érthetően jóval lassabban, így például tele lehet őket szórni kismillió ilyen-olyan letöltést segítő szarral és bízni benne, hogy azokkal már csak-csak sikerül letölteni azt a ritka könyvet vagy más, nehezen beszerezhető tartalmat, amire szükségünk lenne. Ha sikerült, a letöltött tartalmat még a virtuális gépen futtatott böngészőben feltolhatjuk a https://www.virustotal.com/ -ra, ami szignatúra alapon ismeri fel a kártevőket, vagy a Checkpoint Threat Cloudjába, ami pedig emulál egy Windows XP-s környezetet, ott megfigyeli a fájl viselkedését és megítéli, hogy biztonságos-e.

Ha egyik sem talált semmit, de még mindig igencsak paranoidok vagyunk és hallottunk már róla, hogy céges környezetben a vírusfertőzések közel fele úgy történik, hogy az emailben érkező, legitim PDF-nek tűnő csatolmány fertőzött, azaz a dokumentum szöveges tartalmán kívül rosszindulatú kódot is tartalmaz, az eleve PDF fájlt nyomtassuk ki például a PDF995 progival szintén PDF-fájllá. Ezt követően pedig a virtuális gépen például egy eldobható postafiókon keresztül a fájlt elküldhetjük önmagunknak.

Ha már PDF-ekről van szó, itt jegyzem meg érdekességként, hogy a helyzet már annyira súlyos, hogy a Checkpoint tömeges PDF-tisztító megoldást kínál szinte bármekkora cég számára, ami annyit csinál, hogy a beérkező emailekben lévő PDF-eket újra PDF-fé "nyomtatja" és csak ezt követően engedi a felhasználó postafiókjába.

Tehát elvileg virtuális gépet használva sokkal biztonságosabban lehet torrenezni a legelborultabb helyekről is. Hozzáteszem, számomra ez mondjuk azért nagyon fontos, mert ha meglátok egy jó könyvet a neten, annak sokszor pusztán a tartalomjegyzékéből vagy néhány megjeleníthető oldalából nem derül ki, hogy tényleg olyan könyv-e, amire szükségem van. Ugyanis míg régen többen megvettek egy könyvet printbe, amit aztán olvasgathatták ebook formában is a könyvhöz kapott hozzáféréssel, mára pont fordítva van, azaz olvasunk, azaz először megnézem a könyvet ebook formában, aztán ha azt látom, hogy tényleg nagyon jó, a több száz oldalt nem képernyőről fogom elolvasni, hanem inkább megrendelem printbe.

Megjegyzem, hogy az alkalmazott magatartástudomány engem érdeklő tájain, a social engineering és az open source intelligence területén persze, számomra nagyon sok átfedés van könyv és könyv közt, viszont azért sokszor van bennük valami egészen új is vagy a szemléletmódja más. Például nemrég egy barátomnak beboltoltam szülire Chris Hadnagy Social Engineering: The Art of Human Hacking című alapművét, ugyanakkor ugyanettől a szerzőtől a nemrég megjelent Unmasking the Social Engineer: The Human Element of Security könyvet, ami csak minimálisan fed át az előzővel és - most tessenek figyelni! - ahogy azt valahogy megsejtettem pár évvel ezelőtt, az látszik, hogy a legszofisztikáltabb social engineering és azt megelőző technikák döntően a nonverbális kommunikációra és többször a nyelvtudományból átvett kutatásokra alapoznak.

Egyébként meggyőződésem, hogy a nyelvtudományi kutatások közül nagyon sokminden annyira átcsorog majd az információbiztonság területére, hogy azt korábban aligha hitte volna valaki.

//ami kimaradt
0x100. Ha még nem tudod, hogy mozdonyvezető legyél, tűzoltó, katona, vadakat terelő juhász, esetleg víruskutató, két könyvet emelnék ki amolyan iránymutatásként:

A vírusvédelem művészete - Szőr Péter
Hacking Exposed: Malware & Rootkits Secrets & Solutions Paperback - Michael Davis, Sean Bodmer, Aaron LeMasters

0x200. Ami a posztból kimaradt, hogy természetesen a virtuális géppel történő trükközés sem bombabiztos megoldás, hiszen elvben előfordulhat, hogy a virtualizált környezetet biztosító alkalmazás egy hibáját egy intelligens malware úgy használja ki, hogy kitör onnan és eléri az éles operációs rendszert. Ismétcsak lehetnek olyan malware-ek, amik egyrészt jóideig lappanganak, másrészt több trükköt próbálnak bevetni annak megállapítására, hogy amin futnak, éles operációs rendszer vagy virtuális gép.

0x300. Remekül mutatja, hogy mennyire nem szabad elhinni semmit kapásból, amit a neten olvasunk, az az eset, amikor az uTorrent kliensre fogták rá, hogy a felhasználók tudta nélkül bányássza a bitcoit, amit komolyabbnál komolyabb lapok közöltek le, aztán persze egy tényleg komoly lap utána is nézett és kiderült, hogy erről ebben a formában szó sincs. 

képek: bluecoat.com, pcmag.com, github.io

Megszámolni is reménytelen lenne, hogy eddig mennyi levelet kaptam, annak apropóján, hogy mennyiért török FB-fiókot, én meg elvből minden levelemre válaszolok, legfeljebb egy mondatban, már annyira nem vicces. Korábban még vicces volt, főleg az, amikor az illető lobbizott még egy-két kört, amiben arról bizonygatott, hogy igenis igazságos lenne már azt a FB-fiókot feltörni mert az övét is feltörték, mert kell belőle egy bizonyító levél, mert az exe, mert csak úgy, mert a tag egy tetű, mert lehet, hogy megcsalják, mert csúnyán nézett, meg amit csak el lehet képzelni. Szóval az indítékok nem túl változatosak, a legtrükkösebbek komolyan azok voltak, akik úgy adták be, mintha saját magukat csukták volna ki, de nem tudják egyedül helyreállítani a fiókjukat.

Na, akkor most egy kis matek, szerintetek mennyi olvasó tévedt csak idén a blogra csak a Google keresési találatain keresztül, amiben benne volt a facebook feltörés vagy ahhoz nagyon hasonló keresőkifejezés? /*A százalékban kifejezezz értékek nem az összes, hanem csak a facebook kifejezést tartalmazó keresések eloszlását mutatják. */ Oké, akkor segítek:

Ezennel pályázatot hirdetek olyan sablonlevél megfogalmazására, amit azonnal felhasználhatok, alig kell valamit igazítani rajta és mehet is válaszként, a leghülyébb is megérti, hogy NEM BAZDMEG, NEM!!!, ötletes, humoros, ha sértő a címzettre nézve, nem sértőbb a feltétlenül szükségesnél, nem olyan, amire valószínűleg emberünk még egyszer visszakérdez.

Pályázni július 15-éig lehet a blog oldallécében lévő email-címemre küldött mintával, a legjobb pályamű megalkotójának jövök

EGY TÁLCA SÖRREL és egy kurva nagy Tor projectes matricával

amit legnagyobb valószínűséggel Budapesten tudok odaadni.

Pályázni lehet csapatban is, egy pályázó több pályaművet is beküldhet, nem értesítek senkit a levél kézbesítődéséről, de tessék lenyugodni, nálam semmi sem veszi el spambe. Hajrá! /*csak reménykedni tudok benne, hogy nem rántom magam után a Streisand-effektus egy mutációját*/

Ja, életemben először leírom már én is: kérlek oszd meg a posztot, ahol tudod :)

kép innen: interpretermag.com

Az adatközpontokról mindenkinek rácsok mögötti, hűtőszekrény méretű szilíciumszörnyek vagy éppen zsúfolt, kisebb, asztali gépekhez hasonló masinákkal teli tömött polcok jutnak eszébe. Arról már jóval kevesebbet tudunk, hogy az adatközpontok ténylegesen hogyan is működnek és mikben változott az adatközpontok kialakítása az idő folyamán.

2-3 évvel ezelőtt még többen határozottan azt jósolták, hogy a jövő kis- és középvállalati környezetben a mikroszervereké, azaz az olyan szervereké, amik nem sokkal nagyobbak, mint egy asztali gép, csak éppenséggel a rendelkezésre állásuk sokkal nagyobb, emiatt persze egy átlagos asztali géphez képest drágábbak is. A mikroszerverek piaca ha nem is torpant meg, a kezdeti felfutás lelassulni látszik, vélhetően azért, mert ha a szerver többek közt attól szerver, hogy folyamatosan működnie kell, elfogadhatatlan, hogy a 2-3 év garanciális időszak után egy-egy ilyen kis szerver egy hardverhiba miatt leálljon és bizony ha nincs a kkv-nak szerződése valamilyen hosztingszolgáltatóval, amelyiknél egy tartalékszerver át tudná venni a mikroszerver feladatát, akkor az érthetően komoly kellemetlenség, mivel mikroszervert javíttatni nem is olcsó, másrészt veszélyeztetheti az üzletmenet-folytonosságot, akárcsak más leállás.

A megoldások egyike tehát nagyon sok esetben a klasszikus ún. polcos vagy rackszekrényes elhelyezés egy jól védett szerverhotelben, ahol nem kell számolni a porral, hőmérsékletingadozással, ingadozó páratartalommal, elektromágnesesség okozta zajjal vagy éppenséggel az olyan áramszünettől, amit a szünetmentes táp ne tudna áthidalni.
Hiszen a szerverhotelek tipikusan több, egymástól független, nagyteljesítményű betáppal vannak ellátva, nagyteljesítményű szünetmentes tápok gondoskodnak róla, hogy egy-egy áramszünet esetén se maradjanak a vasak áram nélkül, ha pedig még ezek a monstrum méretű szünetmentes tápok sem bírnák szuflával tovább, az szerverhotelek közelében vagy tetején elhelyezett dízelgenerátorokkal biztosítják az áramellátást, ugyan úgy tudom, hogy dízelgenerátorok beindítására Magyarországon még egyszer sem volt szükség a komolyabb adatközpontok esetén.

Dízelgenerátorok a tetőn [Dataplex]

A közelmúltban megtartott IDC Adatközponti Transzformáció Konferencián az adatközponti infrastruktúrákkal foglalkozó és céges ügyfélként jelen lévő részvevők oszthatták meg egymással a tapasztalataikat.

Szinte mindegy, hogy milyen infrastruktúráról van szó, máig a hibrid rendszerek a jellemzőek, azaz klasszikus dedikált szervergépek, nagy számításigényű és magas rendelkezésre állású mainframek  és felhő-alapú megoldások vegyesen.

Ami némileg meglepő lehet, hogy a 64 bites architektúra a nagyszámítógépek piacán csak szép lassan terjed ki, míg az asztali gépeknél és a laptopoknál már természetes, hogy mind 64 bites, ugyan 8-10 évvel ezelőtt a 64 bites architektúrák nem jelentettek a felhasználók számára akkora érezhető változást, mint korábban a 16 bitesről a 32 bitesre történő áttérés.
Ma már a tudatos otthoni felhasználónak sem kell tartania tőle, hogy komolyabb adatvesztést szenved el, ha elszáll a gépe, hiszen jobbnál-jobb cloud storage szogláltatók jelentek meg, amik folyamatosan feltalicskázzák a felhasználói adatokat a felhőbe, aminek tartalmát folyamatosan szinkronizálják a gépen, helyben tárolt
tartalommal.

Kis- és közepes méretű vállalatok szerverei esetén nyilván sokkal kackiásabb a helyzet. Az IDC-n az adatbiztonságra specializálódott Veeam regionális menedzsere egészen elképesztő adatokat osztott meg a hallgatósággal. Kiderült, hogy a felhő-alapú tároló megoldásoknál egy-egy leállás esetén az esetek közel 20%-ában lépnek fel súlyos nehézségek illetve a visszaállításkor. A cloudban alapvetően annyira bízik mindenki, hogy szinte sosem tesztelik. Egy-egy virtuális gép újraindítása egy kkv-nál olyan módon, hogy minden zökkenőmentesen haladhasson tovább, átlagosan négy órát vesz igénybe. Márpedig - ahogy erről többször is írtam ezen a blogon - egy-egy óra downtime társadalmi hatása időről időre egyre nagyobb, az érintett cég számára egyre nagyobb presztízsveszteséget jelent és a kiesésből adódó költségek is egyre nagyobbak.

Állítólag egy, a közelmúltban történt pénzintézeti szerverleállás 880 ezer USD veszteséget jelentett óránként.

IBM AS400 - napjainkig az egyik legelterjedtebb mainframe pénzintézeti környezetben

A Veeam előadásában elhangzott, hogy egy teljes adat- és szolgáltatásvisszaállítás meghibásodás esetén akár kevesebb, mint 15 perc alatt is megoldható. Itt persze nem arra kell gondolni, ami még régen volt IT-üzemeltetési gyakorlat, azaz, hogy - egyszerűsítve - "tükörszerverek" futnak egymással párhuzamosan így biztosítva a redundanciát, nem is úgy kell elképzelni a helyreállítást, mintha egyszerűen csak biztonsági másolatokat kapnának elő, hiszen azok természetükből adódóan nem tartalmaznák a legfrissebb adatokat illetve a kiesett szolgáltatások utolsó ismert állapotát. Valójában ún. replikátumokról, ha úgy tetszik, élő másolatokról van szó.

Egy másik előadásban volt róla szó, hogy a sok, különböző gépből álló szerverpark felügyeletét segítő integrált felügyeleti megoldások egyszerre képesek figyelni az infrastruktúra minden rezdülését és beavatkozni, ha kell. A központi felügyelet pedig nagyon nem mindegy, ha egy több ezer, ráadásul különböző platformon futó, különböző földrajzi helyen lévő gépekről van szó, amiknél nyilván igencsak veszélyes üzem lenne, ha csak külön-külön lehetne menedzselni. Ez utóbbinak az a magyarázata, hogy sokszor a nagygépes vagy több gépből álló rendszerek olyan módon futtatnak párhuzamos folyamatokat vagy éppenséggel biztosítanak virtualizált környezeteket eltérő szolgáltatásokhoz, hogy az IT-s nem is tudja valójában, hogy melyik melyiken fut fizikailag.

A HP előadásában volt róla szó, hogy a big data szép is, jó is, viszont azért, hogy egyre kifinomultabb módszerekkel lehessen hasznát venni, szükségszerűen olyan infrastruktúrára lesz a közeljövőben szükség, amik ma még nem elterjedtek.

Márpedig a jövőben a big datával tudnia kell bánnia minden olyan cégnek, ami meg szeretné tartani a versenyképességét, hiszen a hatékony üzleti tervek kialakításához nyilván jó minél pontosabban tudni, hogy hogyan optimalizálhatóak a belső folyamatok, hogy mit szeretne az ügyfél, arra mennyit hajlandó költeni és ez milyen paraméterekkel áll összefüggésben, amire a big data előtti korban esélyük sem lett volna rájönniük a kutatóknak.

Megjegyzem, ebben a posztban most nem megyek bele, hogy a big data mennyire buzzword vagy sem, na meg abba sem, hogy milyen bizarr módon néz ki, amikor egy aktuális tudományos vagy technológiai paradigmáról irritálóan sokan beszélnek a megrendelői oldalon olyanok, akiknek amúgy lövésük nincs a témáról. Ami viszont tény, hogy igencsak tekintélyes számítási kapacitásra és ehhez igazodó infrastruktúrára szükség lesz, ennek pedig szerintem is egyik flagshipje a HP, ha az igények kiszolgálásáról van szó. Ma ha egy szervezet hatékony szeretne lenni, a meglévő adattárházát az általa megbízott big datával foglalkozó cégnek úgy kell használnia, hogy úgymond minél jobb kérdéseket tudjon feltenni, ennek megfelelően minél részletgazdagabb válaszokat tudjon visszajuttatni a megrendelő szervezethez, ehhez viszont erős infrastruktúra kell.

A DevOps megközelítéssel a Prezi előadása foglalkozott behatóan. Akinek nem lenne ismerős a DevOps, nos, ez az a szemléletmód, ami azt vallja, hogy a szoftverrendszerek fejlesztői legyenek annak üzemeltetői is egyben. Aki nem foglalkozik informatikával, elsőre még így sem biztos, hogy világos, hogy miről van szó, hiszen elvben az informatikus tud szoftvereket fejleszteni, na meg üzemeltetni is, nem? Nos, az egyszerűsített válasz persze az, hogy valóban, viszont nyilván van, aki az idő folyamán a fejlesztésre, tesztelésre megint más pedig az üzemeltetésre specializálódik. Nagyméretű szoftverrendszerek pedig akkor működhetnek a legnagyobb hatékonysággal, rendelkezésre állással és persze leggyorsabban, ha a fejlesztőnek minél inkább pontos képe van arról a környezetről, azaz architektúráról, amire ténylegesen fejleszt valamint az admin-szemléletű informatikus képben van azzal kapcsolatban, hogy a sok-sok különböző technológiát használó szoftverrendszer alá hogyan érdemes beállítani a vasakat vagy éppen a felhőt.

A DevOps igazából kicsiben nem igazán értelmezhető dolog, viszont ha már arról van szó, hogy egy szolgáltatásnak percenként adatbázis lekérdezések milliárdjait kell végrehajtania nyilván megfelelő sebességgel, akkor a szolgáltatás által küldött adatbázis-lekérdezéseket kell optimalizálni ÉS az adatbázisszerveren a célnak leginkább megfelelő adatbáziskezelő motort kell választani, különben a szolgáltatás vagy lassú és megbízhatatlan lesz vagy veszett nagy összegeket kell a cégnek költenie arra, hogy meglegyen a megfelelő erőforrásigény. Az IT-re fordítható pénz pedig nyilván szűk keresztmetszet, azaz többet ésszel, mint erővel.

A klasszikus fejlesztési módszertanról és az agilis fejlesztésről szóló kerekasztal beszélgetésnek megvoltak a maga tanulságai. Megjegyzem, amikor ez kerül szóba valahol, többször tapasztalható, hogy úgy teszünk, mintha egyedül a V-modellel gyakran tévesztett vízesés-modell és az agilis fejlesztési módszertan létezne, holott van még bőven, másrészt gyorsan belátható, hogy az egyik nem váltja fel a másikat időben, hanem tisztában kell lenni azzal, hogy bizony, van, ahol az egyik, van, ahol pedig a másik fejlesztési módszertan hatékony. Ahogy az egész ipar, természetesen maga a fejlesztő is folyamatosan az idő szorításában dolgozik, tény, hogy időt spórolni valahogy a tesztelési folyamatoknál /*veszélyesen rossz*/ szokás. Az olyan módszertanokat követő fejlesztők, amik hallgatólagosan sokkal kisebb hangsúlyt fektetnek a tesztelésre, később komoly árat fizethetnek emiatt.
IMHO persze nincs általános képlet, megfelelő szoftverfejlesztési igényhez a megfelelő módszertant kell kiválasztani, igazán tragikusan például akkor sülhet el a dolog, amikor egy csapat olyan módszertant választ, amit esetleg saját maga talált ki vagy egyszerűen nincs elegendő rendelkezésre álló tapasztalat a hatékonyságával kapcsolatban.

Az IDC-n kiderült, amiről korábban csak pletykák voltak, nevezetesen, hogy a Raiffeisen Bank, kulcs fontosságú rendszerét ért leállást egy IBM AS400-as mainframe egy processzorának elfüstölése okozta, ami rántotta magával a többi hardverelemet. Ismereteim szerint ennyi még bőven kevés ahhoz, hogy egy pénzintézeti rendszer órákra elszálljon, emellett több, konkrétabban meg nem nevezett emberi eredetű hibát is elkövettek a helyreállítás során. Tehát az eset tanulsága ismétcsak az, hogy a leállást kizárni még méregdrága, többszörösen redundáns infrastruktúrával sem lehet biztosan, viszont nagyon nem mindegy, hogy a kiesett rendszer mennyi idő után áll talpra illetve veszi át a szerepét egy tartalék rendszer, ennek a gyakorlata viszont nyilván emberi tényező. Hogy mennyire részletes és szigorú annak a forgatókönyve, hogy különböző kieséseknél milyen protokoll szerint kell eljárni, nagyban függ attól, hogy milyen szektor informatikai rendszeréről van szó, ezzel a ISO/IEC 27000 szabványcsalád foglalkozik behatóan.

Közel teljes rendelkezésre állás létezik. Ez viszont nem csak a technikai kialakítástól, hanem az azt üzemeltető IT-stafftól, mint emberi tényezőtől is függ. Hogy a technikai megvalósítás mennyire is tud redundáns lenni, az IDC egyik előadójának a HP-nak egy ősrégi reklámjával szemléltetném.

A hekkelésről mindenkinek, akinek lövése nincs a témáról, valamiféle feketemágia jut eszébe, amit aztán nem tanulhat meg akárki, na meg makacsul tartják magukat bizonyos jól ismert, ámde még hülyébb elképzelések a hekkerekről. A leginkább közkeletű elképzelés Magyarországon alighanem az, hogy a hekker egy kivételesen  okos informatikus, aki aztán mindent lát mindig, kicsit bűnöző ugyan, de amolyan szerethető cukorpofaként a digital age robin hoodja, ezért kicsit megéri fosni tőle, amúgy meg teljesen öntörvényű és ha azzal bízzák meg, hogy törjön fel valamit, az is megcsinálja, na meg ha azzal, hogy tesztelje valaminek a törhetőségét, azt is, ugyanannyi pénzért.

Ahelyett, hogy hosszasan elkezdenék filózni rajta, hogy mennyire nincs így és miért, néhány megállapítást tennék: mindenki, akivel találkoztam és "hekkernek" vallotta magát /*azaz nem ethical hackernek, szoftvertesztelőnek vagy hasonlónak*/, mind valami szerencsétlen volt, akinek egy jó drága tanfolyamon kimosták az agyát főzőprogramon, aztán kapott egy papírt róla, hogy elvégezte, amit meg tud, annál jóval több megtanulható még egyetlen átfogó kötetből is. Vagy éppenséggel még ennyi se, nem végzett semmit az illető, az önképével meg olyan elégedetlen, hogy kitalálta, hogy ő márpedig hekker, úgysem nézi senki hülyének /*egy darabig*/, pont azért, mert ez amolyan kényelmesen ködös fogalom, amiről valami egyszerű lélek azt hiszi, hogy trendi. Nem keverendő az angol hacker kifejezéssel, de nem is nyelvészkednék tovább.

Nagyon röviden: nulla informatikai tudással és nulla ötletességgel, ilyen-olyan netről letöltött, játékprogram bonyolultságú szirszarokkal bárki okozhat komoly károkat szinte bárki, ugyan ehhez az is szükséges, hogy az áldozatban annyi biztonságtudatosság se legyen, mind Medve sajtban a brummogás. Az ethical hacking/pentesting/vulnerability research/social engineering meg teljesen más sportágak, viszont az ITsec-es, ha a foglalkozásáról kérdezik, legjobb, ha mond bármi mást, de komolyan, mégpedig azért, hogy magyarázni se kelljen, na meg ne is értsék félre. Ne keverjék az olyan idiótákkal, akikről most szó lesz.

Az alapsztorit amúgy a 403 Security CEO-ja jelentette meg még 2011-ben, mondjuk azóta jó sok adat átfolyt a BIX-en én ma olvastam így egyben először, ezért gondoltam, hogy sederítek róla egy posztot, alaposan kiegészítve. Az alapsztorik hitelességének ellenőrzésébe nem mentem bele, de ígérem, a végére világos lesz, hogy ez mellékes is, ahol kellett böktem bele egy kis lábjegyzetet [így számozva].

0x100. Még 2010-ben egy közelebbről meg nem nevezett valaki egy népszerű brit énekesnő, Kelly Osborne /*akinek nincs meg:  Ozzy bácsi és Sharon néni lány*/ email fiókját törte fel. [1] Ezt követően beállította, hogy a leveleket a levelezőrendszer továbbítsa egy adott címre [2], ámde nem egy erre a célra létrehozott, gondosan anonimizált fiókra továbbította hősünk a leveleket, hanem a saját, valódi email címére, ami alapján nem volt olyan pokolian nehéz azonosítani.  

0x200. Shahee Mirza, egy önmagát hacktivistának és géniusznak nevező 21 éves hülyegyerek bangladesi kormányzati webszervereket tört fel és azokon helyezett el remekebbnél remekebb nyelvhelyességgel írt üzeneteket, amiben felszólította a kormányt, hogy a számítógépes bűnözés elleni törvényeket módosítsák, mert ők, hacktivisták akkora zsenik, hogy úgyis feltörnek bármit. A dolog egyik pikantériája, hogy ugyanazt a dumát közel 20 webhellyel megcsinálta. Úgy bukott le, hogy elhelyezett a deface-elt oldalak alján egy olyan logót, amiben benne volt a neve. [3]

0x300. Samy Kamkar a MySpace egy sebezhetőségét felhasználva [4] útjára indította a Samy Wormöt, ami rommá fertőzött egymillió accountot, valójában csak annyit csinált, hogy megjelenítette a felhasználók képernyőjén a "Samy is my hero" üzenetet. Érdekes lélek lehet, mert ennyivel nem érte be, még a blogján is alaposan beszámolt a nagy hekkelésről, a kínos csak az volt, hogy a blogján volt egy kép a kocsijáról is - hát hogy ne lett volna - amin tisztán látszott a rendszáma, ami egyértelművé tette, hogy tényleg ő volt az elkövető. Na innentől nem volt nagy kriminalisztikai bravúr azonosítani. Az alkalmazott módszer egyébként nagy hasonlóságot mutatott azokkal a perzisztens XSS-támadásokkal, amivel a jó öreg iWiW-et is megkínálták néha. 

0x400. Daquan Mathis New Yorkban ellopott egy iPhone-t, de nem csak gyönyörködött benne, hanem csinált magáról egy rakás szelfit, nem mellékesen ugyanabban a ruhában, amiben a rablást vagy lopást elkövette. Nos, ehhez már alapjáraton hozzáfért az iPhone tulajdonosa /*már akkor is*/, amelyiknek az accountjaiból nem jelentkezett ki. Ha mindez még nem lett volna elég, a képeket a tolvaj a saját email címére küldözgette, ami szintén látható volt - és megdönthetetlen bizonyíték az év kiberbűnözője ellen. Itt hozzáteszem, hogy Magyarországon egy zsebesnek még ezt a szintet is sikerült messze felülmúlnia: miután csinált magáról egy adag szelfit, feltöltötte az eredeti tulajdonos Facebook-accountjára, ahogy arról a 444 beszámolt

0x500. Még 2006-ban egy Eduard Lucian Mandru nevű pofa, aki bejutott a DoD egyik - szerintem szándékosan legyengített - gépére, a védelmi minisztérium sokáig ennek ellenére semmit nem tudott róla az email címén kívül /*de valószínűbb, hogy ez a DoD részéről taktikai blöff volt*/. Emberünk néhány évvel később ugyanazt az email címet használta különböző álláshirdető-álláskereső oldalakon.

0x600. A hatodik nem igazán illik a képbe, de azért... Egy forma tisztában volt vele, hogy az USA-ban bizonyos helyeken, ahol tábla is jelzi, hogy lassítani kell a kocsival, a gyorshajtók rendszámtábláját egy rejtett kamera felveszi, majd ezt egy optikai karakterfelismerő szoftver átalakítja sima karakterlánccá, ahonnan már szintén gépileg mehet abba a nyilvántartásba a rendszám, amiben a kocsik tulajdonosait jegyzik, hogy könnyen elő lehessen venni a gyorshajtókat. Ötletes, nem? Amivel a pofa próbálkozott, még ötletesebb akart lenni és a rendszáma helyére egy olyan táblát tett, amit ha a rendszámnyilvántartó megkap, nem egyszerű szövegként fogja kezelni, hanem végrehajtható parancsként és konkrétan törli a teljes adatbázistáblát. A veszett nagy trükk a "ZU 0666......" rendszámmal ugyan alighanem nem jött be, de a hékek eléggé gyorsan nyomára akadtak a tagnak. Az SQL befecskendezésnek
nevezett támadás lényege, hogy ahol egy szolgáltatás bemenete szabályos adatot, tipikusan szöveget vár, meg is kapja, majd azt belefoglalja az adatbázislekérdezést ténylegesen elvégző függvénybe, viszont ha a szerver nincs rá felkészítve, hogy csak olyan adatot engedjen tovább, ami oda ildomos, elvben beküldhető olyan szöveg, ami egy adatbázisműveletként értelmeződik majd, például rekordokat vagy táblákat módosít, töröl, na meg amilyen jogosultsággal a szolgáltatás indította a függvényt. A tanulság az, hogy bemenetet - meg úgy egyáltalán semmit - nem adunk át azonnal feldolgozásra, hanem azt alaposan ellenőrizzük, mielőtt egy felületről egyenesen menne feldolgozásra /*jelen esetben pedig jó esetben nem végrehajtásra*/ a szerver gyomrában.

Egy korábbi posztomban már utaltam rá, hogy még pár évvel ezelőtt, amikor reggeltől estig dagonyáztam a dark web mocskában, azaz az internet azon tájain, amerre ember nem jár, ha nem nagyon muszáj, konkrétan személyek hitelességét ellenőriztem és persze nap, mint nap beleakadtam valami pöcsbe, aki pénzért árult meghívókat olyan közösségi szolgáltatásokba, ahova nem lehet csak úgy regisztrálni. Bizonyos szolgáltatásokba kizárólag egy vagy több tag meghívása alapján lehet belépni, a meghívókat pedig nem osztották két kézzel - márpedig ami csak korlátozott mennyiségben hozzáférhető, értelemszerűen vonzó, ha van benne racionalitás ha nincs. És bizony lesznek arcok, akik az emberi természet ezen mesés vonását ki fogják használni. Többször is találkoztam például kőburzsuj amerikai nyugger bőrébe bújva olyan formákkal, akik mondjuk az AsmallWorld-höz, ELIXIO-hoz vagy BestOfAllWorlds-höz kínáltak meghívókat szaros ezer dollárért, amit rendszerint lealkudtam 50 dollárra, a csaló pedig szintén kitett magáért, mondjuk amikor olyat írt, hogy biztos csóró szar amerikai vagyok, ha nem utalom a pénzt még aznap egy Paypal/Moneybookers/Skrill-számlára, amire ugyebár, ha tényleg öreg amcsi nyugger lennék alighanem az egó miatt azonnal fizetnék is. Na, fizetni nem fizettem, hanem amikor már rég tudtam, hogy a csaló honnan netezik, milyen oprendszerrel, böngészővel, mik azok a kamu identitások, amik szintén hozzáköthetőek, nem küldtem neki valami finomat a gépére, amivel bűncselekményt követtem volna el, inkább megírtam, hogy azonnal fizetek, de küldjön egy képlövést a szolgáltatásról, hogy meggyőződjek róla, hogy tényleg tud onnan meghívót küldeni.

A harceddzettebb webcserkészek kitalálhatják, hogy milyen screenshotot kaptam emailen, többször is: amin látszott a szolgáltatás, a másik böngészőfülön pedig befigyelt névvel/címmel a tag valódi (!!) Gmail/FB profilja. És ezek az arcok egész nap azzal foglalkoztak, hogy az USA-ban, na meg Európa burzsujabb részein lakó felhasználókat húzzanak le nem túl ékes angolsággal. Ugyan eléggé határozott volt a trend, hogy ez hol biznisz, leszek most olyan polkorrekt, hogy nem írom meg. A jelenség természetéből adódóan a tettesek elvben könnyen azonosíthatóak, gyakorlatilag meg a büdös életbe sem, hiszen a Paypal-nek az egyik lényege, hogy nem tudni, kihez tartozik a számla, amíg több ország hatósága összefogva ki nem kéri a számlatulajdonos adatait - amihez persze nincs joga. A károsultaknak pedig többszörösen indokolt okból úgysem tesznek feljelentést, azzal a szöveggel, hogy voltak olyan hülyék, hogy fizettek valakinek, akiről fogalmuk sincs, hogy kicsoda, de azért fizettek, mert egy elit közösségi szolgáltatásba akart bejutni, ahol nincs valódi ismerősük, aki meghívót küldhetne, tehát eleve illegálisan. Akinek hatalmas az egója, na meg még hülye is, azzal még nem érdemli ki, hogy lehúzzák pénzzel.

Na, ilyen cybercrime-os blogot mondjuk fix, hogy nem írok, ha meg mégis, akkor majd valamikor a jövőben, mondjuk kinyíratni magam nem akarom, szóval álnéven, de lenne mit írni azokról a manipulációs fogásokról, amiket a bűnözők és a nyomozók is alkalmaznak, arról nem is beszélve, hogy a csalók többségének annyi esze nincs, hogy a lebukást megelőzve legalább ne olyan fantom karaktert használjanak, amit azonnal dob a Google képkereső, sátöbbi.

[1] Amikor két droid arról beszél, hogy hogyan törték fel valakinek a Gmail/Facebook fiókját, a leggyakoribb esetek:

0x100. a felhasználói név ismert, a jelszó pedig valami elképesztően banálisan kitalálható szó, mondjuk "password"
0x120. a felhasználói név ismert, a jelszóemlékeztető vagy jelszóhelyreállító opció pedig pofátlanul egyszerű: új jelszó beállításához a rendszer megkérdezi mondjuk, a születési időt /*vagy bármi olyan adatot, ami full nyilvános*/, a helyes választ a támadó megadja és ezzel új jelszót állít be, amivel már be tud lépni. Én azt mondom, hogy alapvetően minden password recovery rossz, de ha már az ilyen Security questions a téma, na, azt akik tervezték, feltételezték, hogy a felhasználónak lesz annyi esze, hogy olyat állít be, amit nem banalitás tudnia vagy kitalálnia bárki más számára is.
0x130. letöltenek egy önmagát képfájlnak álcázó keyloggert a netről, majd elküldik emailen csatolt fájlként az áldozatnak, aki annak ellenére, hogy nem ismerős neki sem a feladó, sem a tárgy, meg úgy általában semmi, mégis van olyan hülye, hogy megnyitja, a víruskergető szoftver meg vagy megfogja vagy sem. Amikor a jelszót legközelebb beírja, azt a keylogger elküldi a támadónak. A játékprogramok egy része több intellektust igényel, mint egy ilyen konzerv-keyloggerrel támadni.
0x140. odamennek ahhoz a géphez, amit általában használ az illető, majd a böngésző beállításaira kattintanak és ott az elmentett jelszavaknál rákattintanak a jelszavak megjelenítése gombra... /*na, ez már a többségnek az advanced level*/

Tehát gyakorlatilag sosem az authentikációért felelős programhiba kihasználásáról, az adatokat ténylegesen tároló adatokhoz egy sérülékeny szerverszolgáltatáson keresztüli eléréséről, a kliens és a szerver oldal közti titkosított kommunikáció lehallgatásáról, stb, stb, stb. van szó. Amúgy innen is csókoltatom az összes idiótát, akiktől hetente legalább 2-3 levelet kapok "feltörnéd az exem fészbúkját?" témában, mióta egy ezzel kapcsolatos Facebook-cikkem megjelent.

[2] Ha már email átirányítás, ilyen beállításánál újabban még a legkommerszebb levelezőrendszerek is alul vagy felül egy csíkban, na meg ahogy tudják, figyelmeztetik a fiók tulajdonosát, hogy a levelei át vannak irányítva.

[3] vegyük észre, hogy itt is az überszuper nagy "feltörésnél" közönséges webszerverekről volt szó, nem pedig a kritikus infrastruktúrákért felelős gépek valamelyikéről. Magánvéleményem, hogy a NASA és az NSA korábban szándékosan alakította ki úgy a webhelyeit, hogy az a hülye, ámde elszántságuk miatt veszélyes aktivisták számára feltörhető legyen, majd miután elkapták az illetőt, már gyerekjáték volt feltérképezni ilyen-olyan potenciálisan underground csoportokat, amikbe az elkövető tartozott. Az általánosan bevett technika eredetijét honeypot-olásnak nevezik, ennek kifinomultabb, gyakorlatilag végtelenségig cizellálható változata a tar trapek használata, aminek az a lényege, hogy miközben emberünk reszeli a szervert, mindig egy kicsit nehezítünk valamit a védelmen, de vannak erre automatizált eszközök is, lényeg, hogy a szerencsétlen ennek megfelelően nyilván annál több nyomot fog maga után hagyni, hiszen a betörés módja sokszor egy adott csoportra jellemző, de jellemző lehet akár egyénre is.

[4] Én a Samy wormről valószínűsítem, hogy a szkript részletet valahol látta a neten, aztán kipróbálta, hogy a MySpace-n működik-e. Egyébként ún. XSS-sebezhetőség volt, amik közül vannak egészen kifinomultak, na meg annyira egyszerűek is, hogy azt a legbölcsészebb olvasó is azonnal megértené. A tankönyvi eset, amikor egy szövegdoboz szöveget vár bemenetként, de olyan kódot, például Javascript-parancsot kap, ami feldob egy kis ablakot egy adott szöveggel vagy valamilyen nem kívánt műveletet végrehajt. XSS-ről bővebben a Wikipedián.

Képek innest: blog.on.com, Wikipedia

Nemrég részt vettem egy workshopon, aminek az volt a tárgya, hogy aki tényfeltáró újságíróként dolgozik, milyen informatikai fenyegetésekre érdemes figyelnie, hogyan lehet a kockázatokat alaposan csökkenteni. Nos, a teljes egynapos workshopon mindössze egyetlen eszközt mutattak be, ami számomra új volt, viszont annál inkább jópofa. Nem innovatív, nem technikai újdonság, de igencsak látványos.

Bizonyára mindenki találkozott már azzal a jelenséggel, hogy hiába csapkodta le a reklámokat ilyen-olyan módszerekkel a böngészőben és az általa látogatott szolgáltatásokban is, ezt követően például egy Googleben indított, fogfájással kapcsolatos keresés után a Facebook oldallécében egy fogorvosi rendelő reklámja virított...

A magyarázat, hogy a személyre szabott hirdetések világában a hirdetések személyre szabott megjelenését nem úgy kell elképzelni, hogy egy adott szolgáltatás határain belül érvényesek, hanem szolgáltatások közt is. Ennek a nagyon rövid technikai magyarázata az, hogy a hirdetéselosztó hálózatok összességében gyűjtik az információkat a felhasználókról, majd azt osztják meg az ügyfeleikkel /*tartalomszolgáltatókkal és közösségi szolgáltatásokkal*/, nem pedig külön-külön, ami érthető módon az egyik legkorszerűbb és leghatékonyabb hirdetési forma, hiszen ha valaki szabad perceiben csak a magyar hírportálok közt nézegeti meg a legfrissebb cikkeket, akkor a célzott hirdetést megjelenítő hálózat nem kezdi újra vizsgálni a felhasználó érdeklődési körét az alapján, hogy hova kattintott, mire keresett vagy éppen hol tartotta az egérmutatót, hanem figyelembe veszi azt is, hogy a korábban meglátogatott szolgáltatásokat és portálokat hogyan használta.

A gráfként megjelenített ábrákat mindenki szereti, mert szépek, elforgathatóak, nagyíthatóak és nagyon beszédesek, bárki számára elérhetőek /*mármint az is tudja használni, aki egyébként nem web-kórboncnok*/. Nincs ez máshogy ebben az esetben sem, maga a Mozilla egy roppant jópofa eszközt ad arra, ha szeretnéd látni, hogy hogyan "beszélnek össze" veled kapcsolatban a hirdetői hálózatok. Néhány pillanat alatt telepíthető a Firefoxhoz a Lightbeam kiegészítő, ami azonnal mutatja is, hogy melyek és mennyire. Persze akkor a leglátványosabb, ha átlag felhasználóként használjuk a netet, azaz nem használunk semmilyen reklámgyilkolót, nem mókoljuk meg a földrajzi pozíciónkat, nem trükközünk kliensoldalon. Az én esetemben valahogy így néz ki a dolgot egy perc kattintgatás után, ugyan szándékosan megnéztem egy review oldalt is, amiről tudom, hogy különösen pofátlan ebben a műfajban:

Google Chrome-ot használsz? Ez esetben sajnálom, lehet, hogy ott is van hasonló eszköz, nem tudom, meg annyira nem is érdekel, pont azért, mert Google, na meg Chrome, nem használom. Viszont érdemes tudni, hogy a nyílt forrású Chromium motor felhasználásával nem a Google Chrome az egyetlen böngésző, ami valaha készült, ha nagyon ragaszkodsz a Chrome-szerű böngészőhöz, a Comodo kapásból háromfélét is ajánl, ami nem akarja eladni az adataid kilóra, sőt, pont az ellenpólust képviseli mind:  
https://www.comodo.com/home/browsers-toolbars/browser.php

Ha már böngészők.

Nem új, de még mindig zseniális az az ismeretlen szerzőtől származó, de erősen Microsoft-gyanus reklámparódia, ami annak idején az egyik Chrome verzió reklámját figurázta ki még az eredeti reklám megjelenésének napján.

Ha pedig már videó, "Kutyával és gyerekkel maguk mindent beszopnak", ahogy mondta a Kiábrándult értelmiségi, és valóban, egy jóval kevésbé offenz', de esztétikus és hatásos böngészőreklámot is ide teszek.

Ebben a posztban egyáltalán nem foglalkoztam azzal, hogy enélkül finanszírozhatatlan lenne szinte minden valamire való - nem-fizetős - szolgáltatás a neten, azzal sem, hogy akár elhiszed, akár nem, ez a hirdetési modell igenis hatással van a fogyasztói döntéseidre, még akkor is, ha tudatosan egy-egy cikk olvasása közben a reklámot nem is olvasod, csak a szemed látókörébe kerül, azzal sem, hogy a reklámdobáló hálózatokat természetesen lehet korlátozni vagy blokkolni, viszont nem szabad túltolni a dolgot, mivel nagyon sok helyen ha a reklám nem jeleníthető meg, nem jelenik meg a tartalom sem, amit megnéznél vagy olvasnál. Amivel szintén nem foglalkoztam, hogy a privacy-fetisiszta jogvédők paranoid óbégatása miért iszonyúan károsak, lévén, hogy nem reális veszélyekről beszélnek, az igenis reális veszélyekről pedig gyakorlatilag sosem ejtenek szót érdemben, ami érthető is, mert ez olyan technikai rálátást és szemléletmódon igényelne, amivel ők maguk sem rendelkeznek. Szintén nem mennék bele, de érdekes téma, hogy a felhasználókról készülő profilalkotás bőven ad lehetőséget visszaélésekre például olyan módon, hogy egy webshop ugyanazért a termékért eltérő árat kér két különböző felhasználótól olyan tényezők alapján, hogy valószínűleg mennyit lenne hajlandó a termékért fizetni, van-e hasonló termékporfólióval rendelkező üzlet hozzá földrajzilag közel és még ki tudja, hogy mi alapján. Ez utóbbi amúgy nem egy konteós elméleti felvetés, hanem bizony-bizony van, ahol már rég alkalmazott módszer: WSJ: Websites Vary Prices, Deals Based on Users' Information. A témát magyar nyelven anarki is alaposan kivesézte pár hónapja.