netbankolás guest-ként

Linux-security

Sziasztok!

Jelent bármi pluszt biztonsági szempontból, ha otthoni gépen (Ubuntu Jaunty) nem a "normál" felhasználóként, hanem Vendég felhasználóra átváltva intézem a netbankos ügyeket? Ilyenkor létrejön a /tmp-ben egy ideiglenes home könyvtár a Vendégnek ami kijelentkezéskor törlődik, a felhasználói profil üres mintha új felhasználó jönne létre, és az egész megszűnik a kijelentkezéssel.

Tudom, ha már feltörték a gépet, akkor semmi értelme. De lusta vagyok mindig live CD-re váltani, ráadásul rokonok / ismerősök is kérdezték, és nekik a live CD nem opció.

  • 4486 megtekintés

( hrgy84 | 2010. 03. 11., cs – 17:54 )

Hat, ha keylogger van a gepen, es rendszerinditaskor indul, akkor nem, egyebkent nem hangzik rosszul. Mondjuk en a laptopot azert lebastyazom, szoval arra tavolrol nem jutnak be, kozelrol meg en dobom meg a tagot a laptoppal ha bele akar piszkitani.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Nekem asztali gépem van vezetékes nettel, úgyhogy ilyen gondom nincs. :)

Gondolom elsősorban a Firefox és a bináris média-pluginek jelentenek kockázatot, esetleg torrent kliens. És pont a fentieket küszöböli ki a mindig 0-ról generált profil és home könyvtár. Viszont nem tudom, hogy ha már beléptem normál felhasználóként és esetleg az én jogaimmal fut valami okosság, akkor azzal mi történik felhasználóváltás hatására - konrétan a guest sessionbeli dolgokra milyen rálátása lehet egy normál felhasználó jogaival futó dolognak.

Hat, gondolkodjunk egyutt. Mivel a guest az valojaban csak a home mappa szempontjabol specialis user, igy valojaban ugyanolyan masik user, mint a te usered. Nomarmost, ket user csak akkor lathatja egymas home mappajat, ha a $HOME mappan legalabb 750-es jog van, es egy csopotban vannak, vagy (ez a rosszabb) ha a $HOME mappan 755 jog van, es nem esnek egy csoportba. Minden mas esetben accdenied van.
Processz szinten valami hasonlo van, hacsak nincs valami kernelbug, nem tudsz piszkalni mas user processeiben.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ez idáig világos. De mi van pl. a teljes képernyő (pl. snapshot miatt) ill. a billentyűzet (pl. keyloggerhez) elérésével? Ezt gondolom az X szervertől kell kérni, és nem tudom hogy normál jogokkal egy processz hozzáférhet-e ezekhez az adatokhoz. Ha igen, akkor mi történik felhasználóváltáskor? Az egy másik "képernyő" és "billentyűzet", amihez már a másik felhasználó nem fér hozzá?

Az X a kereseket authorizalja, valahol valamikor valaki kiexportal egy kornyezeti valtozot, hogy mi a Xauthority fajl elerhetosege, es onnantol az abban a fajlban foglaltak vannak ervenyben. Mivel ez a home konyvtarban van, igy lasd az errol szolo ertekezest.

Keylogger: igazabol ez az egyetlen necces terulet. Ha az X-tol keri el a keyeventeket, akkor lasd az elozo pontot, ha direktbe szerzi meg valami device-tol, az mar neccesebb lehet, de komolyan nem tudom, hogy ez a resze hogy mukodne.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

ha egy másik normál user futtat egy scrot-ot a háttérben, akkor az le fogja menteni a guest user-ed képernyőjét is. egyszerűen tesztelhető, egyik asztalon másik user-rel terminálba:

sleep 5; scrot

másik asztalon netezés közben lementi a guest user által futtatott program képével együtt a teljes asztalt.

viszont jelszavakat általában csillaggal jelölik a weboldalak is gépelés közben, ezért ez miatt nem aggódnék.

a keylogger témához annyit tudok hozzátenni, hogy ismereteim (és emlékeim szerint) normál user-ként az ő usereként futó programok ablakaihoz lehet bill. és egér grab-balést csinálni, tehát attól nem félnék hogy pl. a nomrál user-ed böngészőjén pl. betörnek és futni fog egy keylogger progi ami globálisan tudná grab-belni a billentyűt a guest user-edét is. ehhez szerintem root jogok kellenének mindenképpen, de fixme.

ugyanazon X-en csináltam természetesen, mert gondolom a topic nyitó is arra gondol, hogy azonos X-en belül guest-ként indítja a böngészőt.

másik X-en futtatva biztos hogy nem lehet log-olni szerintem a másik user bill. leütéseit.

"És a velük azonos X-en futó programokhoz"

Ezt konkrétan tudod, hogy sima user-ként el tudok indítani egy olyan folyamatot, ami akkor is pufferelni tudja mondjuk a bill. leütéseket, ha másik ablak aktív másik user-ként futtatva ugyanazon X-en belül?

"Ezt konkrétan tudod, hogy sima user-ként el tudok indítani egy olyan folyamatot, ami akkor is pufferelni tudja mondjuk a bill. leütéseket, ha másik ablak aktív másik user-ként futtatva ugyanazon X-en belül?"

AFAIK Az X nem tud arról, hogy egy klienst melyik felhasználó futtatja. Csak arról, hogy engedélyezve van-e - csak akkor tud egyáltalán X kliensként működni. xmacrorec2 és hasonló programok tudnak bemenetet figyelni - most nem sikerült működésre bírni (korábban már használtam), úgyhogy nem tudtam kipróbálni, de nem hiszem, hogy ha root-ként futó program ablakára váltasz, akkor hirtelen nem működne.

Valójában az a gond, hogy nem tudom hogy működik az X. Az alap kliens-szerver felépítést persze értem, X forward-ot is csináltam már ssh-n keresztül, csak azt nem tudom, helyi gépen mi zajlik a háttérben:

A gdm-mel bejelentkezem normál felhasználóként (jack), aztán a kikapcsolás menüben lehet másik felhasználóra váltani - nálam nincs másik, így csak a "Vendég munkamenet" választható. Ekkor a fent már leírt guest grafikus környezetet kapom a vt9-en Innen a Ctrl-Alt-F7 kombóval bármikor átválthatok a jack felhasználóra, ill. Ctrl-Alt-F9 -cel a guest képernyőjére (vagy a felhasználóváltó menüben most már ott a "jack" és a "Guest" is). Szóval a vt7, vt9-en futó X sessionök (már ha azok) vajon mit tudnak egymásról, elérik-e egymás képernyőjét, billentyű-inputját?

Persze root jogokkal tökmindegy, de tegyük fel hogy odáig nem fajult még a helyzet. :)

Szerintem egy X szerver által kapott billentyűleütéseket (egy root-ként futó keyloggertől eltekintve), ill. képernyőjét csak az adott szerver X kliensei tudják elmenteni. Azt kipróbálhatod, hogy ha a v7-en rendes userként egy terminálban a DISPLAY változóban a v9 számát állítod be, akkor tudsz-e azon X programot indítani - valószínűleg alapértelmezés szerint nem.

( gd | 2010. 03. 12., p – 09:50 )

Ha a kártevő nem tud root jogot szerezni, akkor van értelme. Akkor tud, ha használni tud egy kernel bugot, vagy ha olyan felhasználó jogát szerzi meg, amiből, az Ubuntu okosságágát használva, sudo-zol. Az előbbit az teheti nehezebbé, ha a potenciálisan veszélyes dolgokat is guest-ként csinálod, és persze frissíted a rendszert, az utóbbit pedig az, ha sudo-t nem a szokásos felhasználói fiókodból használsz.

Amúgy itt nincs SMS ellenőrzés, vagy ilyesmi? Vagy az egyenleged is különösen titkos? Ha nem lenne, én nem bíznám a pénzemet másra is használt rendszerre.

Akkor viszont szerintem live CD a minimum. A Linux kis elterjedtségét ki lehet használni (amíg nincsenek hírek, hogy törik a windowsokat, addig nem valószínű, hogy Linux kernel exploitot fognak használni, mert nem valószínű, hogy a linuxosokkal kezdenek), de sok pénzt nem bíznék erre.

kicsit kapcsolódik a témához, az egyik banknál ahol számlafiókom van, belefutottam egy olyan hibába, hogy amikor utalásnál kitöltöm az infórmációs részeket, ki lehet választani hogy kinek utalok. Itt az előre felvett kapcsolatoknál a legördülő listából kiválasztottam valakit, és az ő nevét is írta ki visszajelzésként a weboldal egy másik részén (ez nem szerkeszthető rész, csak sima echo).

a probláma ott volt, hogy másik ügyfél számla számát vette hozzá. én meg ugye megelégedtem csak a név ellenőrzéssel utaláskor. az álmomban sem jutott volna eszembe, hogy ilyen durva hibába létezhet egy bank weboldalán.

3x küldtem rossz helyre az összeget mire rájöttem mi a gond.

Linux-on és XP-n is többször leellenőriztem, és mindegyik rendszeren reprodukálni tudtam a hibát epiphany, firefox és explorer böngészőkkel is. miután ezt leellenőriztem, lejelentettem nekik telefonon. azóta javítva, mert utána megnéztem 1-2 héttel később (pár napig még nem volt javítva az biztos). ez olyan 1 éve történt ha jól emlékezek.

( log69 | 2010. 03. 12., p – 10:03 )

nálam speciel úgy van, hogy schroot környezetben fut a böngészőm és a chat progi. a torrentet is ide tenném.

ennél a felállásnál ugye nem a chroot-on belüli folyamatok vannak védve a külsőtől, hanem fordítva. ha kompromittálódik a chat kliens vagy a böngésző, az bezárva marad.

kernel sebezhetőségnél, ahol privilégium szint emelés érhető el, ez sem tuti.

ezen kívűl hosts.deny-ban ALL:ALL van, tűzfalnál az input és forward tiltva van teljesen, és nem fut egyetlen szolgáltatás sem. ez már nem paranoia, hanem egyszerűen nincs semmi amire szükségem van. de ha lenne, akkor is jó tűzfallal azért szépen be lehet szabályozni.

ha megéri a chroot-os vesződséget neked, akkor szívesen odaadom a script-emet ami megcsinálja a teljes schroot környezetet + leveszi a suid biteket az összes benne lévő binárisról stb.

egyébként a live cd is úgy jó azért, ha netbankolás előtt egy update megvolt imho :)

nem csak kernel bug van, hanem programok is bug-zanak. talán utóbbinál nagyobb az esély. így ha kompromittálódik egy program, attól még nem kap infót a valós rendszeremről, nincs felcsatolt /proc, nincs suid, stb. illetve ugye csak minimális user környezet, mert ugye más proginak még lehet ismert sebezhetősége.

Nekem a chroot-tal egy a bajom, hogy minden loszart oda kell a proginak masolni, ami adott esetben sok is lehet. Pl. egy firefox fugg a fel X-tol meg a gtk-tol meg... Konquerorba bele se gondolok inkabb.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.