root pass

Virtualizáció

Hali,

Nagyon idióta kérdés, ég a pofám miatta, de kénytelen vagyok feltenni, hátha.

Van kb. 100 darab, vmware-rel virtualizált linux.
Ismeretlen root jelszó (meg úgy általában senki nem tud semmit).
Nincs vmi mód arra, hogy a gépek rebootja nélkül, vmware-en át (vcenter, vsphere client, akármi) be lehessen lépni és/vagy root pass-t lehessen cserélni?

Thx.

  • 20133 megtekintés

( zeller | 2016. 05. 17., k – 17:06 )

Cserélni nem igazán - snapshotból/mentésből esetleg kinyerhető a shadow tartalma, de azzal csak annyira vagy előrébb, hogy törni megpróbálhatod; én egyébként megnézném, hogy milyen lukas komponensek vannak telepítve, amiben kihasználható local root sérülékenység van.

( zZsOlTi v | 2016. 05. 17., k – 17:14 )

Csak hangosan gondolkozom: Gondolom klónozni lehet az OS-eket, nem? Klónozod, elindítod a klónt -nem esik ki az élő szolgáltatás- és a klónon a grub-os módszerrel vagy chroottal vagy akárhogy cseréled a jelszót.

Csinál egy klónt, vagy visszaáll mentésből, akárhogy, hálózat nélkül, majd ezen a szolgáltatást nem adó gépen cserél jelszót. Kérdés: mit ér el vele? A nagy semmin kívül - mivel a cél a meglévő, futó gépekhez való hozzáférés. Attól, hogy egy másolaton módosít valamit, attól még az eredeti gépen nem történik meg ugyanaz a módosítás...
A futó OS klónozása meg... Oké, snapshotból megoldható - viszont az a snapshot minden lesz, csak konzisztens nem - oké, fs szinten még akár lehet is, de egy DB, vagy akár egy írásra megnyitott állomány tartalma sérült lesz a snapshot-ból készült másolatob, mivelhogy a vmware nem tud egy vm-ben futó Oracle/Postgresql/MySQL, de akár egy tetszőleges nosql adatbázisnak jelezni, hogy tessen mindent flush, meg "begin backup", hogy konzisztens legyen a DB is.

Én azt vettem le, hogy nem tud semmit. Ha klónoz egyet közelebb jut, lesz információ tud tesztelni. Ezért írtam, hogy nem biztos, hogy kell hálózat. Azért megjegyezném, hogy azért a modern hypervisor rendszerek nem csak a diszket klónozzák és snapshootolják törvényszerűen..

Na jó, de attól, hogy a klónon le lett cserélve a jelszó, attól az éles rendszeren nem változik. A klónra meg nem kéne átállni a produkció után, mert a klónon nem lesznek meg azok a változások, amelyek a klónozás pillanata és a sikeres jelszó csere között eltelt idő alatt történtek. Akkor? Mit nyerünk ezzel?

( fathom | 2016. 05. 17., k – 17:15 )

Amivel próbálkoznék:
- futó OSből egy másolat készítése és indítása
- régi OS-ben lecseréled a root jelszót
- másolatot lelövöd, eredetit elindítod

FathoM

Ui.: mivel elég sok rendszer fut, mindezt szkriptelném is.

( E-Medve v | 2016. 05. 17., k – 17:53 )

Nem volt mögötte valami puppet/chef/stb.?
Esetleg ssh kulcs? (Bár azt ugye rootnak telepíteni nem egy életbiztosítás.)

( lmarton | 2016. 05. 17., k – 18:12 )

Mondjuk meglepne ha ertelmes valaszt kapnal... Egyreszt ugye mert ez elegge alaasna a cloud szolgaltatok / hypervisorok hitelesseget - ambar egyesek szerint ugye minden kinyerheto a futo gepbol, meg a betoltott SSH kulcsok is (legalabbis elmeletileg)... Masreszt ha itt valaki nyilvanosan elerhetove is tenne a modszert, ami gyanitom nem trivialis azt hiszem eleg nagy figyelmet kapna a dolog.

Kivancsinak kivancsi lennek, ra es ertem en az elmeletet, de gyakorlatban en meg nem lattam... Biztos rossz korokben mozgok (vagy tul _jo_ korokben)

A te esetednel mar csak az lenne cifrabb ha encrypted FS is lenne azokon a gepeken :)

Egyreszt ugye mert ez elegge alaasna a cloud szolgaltatok / hypervisorok hitelesseget - ambar egyesek szerint ugye minden kinyerheto a futo gepbol, meg a betoltott SSH kulcsok is (legalabbis elmeletileg)...

El kell, hogy szomorítsalak, tetszőleges VM hoszt korlátlanul hozzáfér a benne futó guest-ek memóriájához. Innentől fogva pedig támadhatóvá válik tetszőleges kulcs, csak tudni kell, hogyan lehet megtalálni.
Lásd például: Don’t Forget Your Encryption Keys in Memory

Tehát bármelyik cloud szolgáltató dönthet készíthet egy snapshotot (memória + diszk) a nála éppen futó szerveredről úgy, hogy te ezt észre sem veszed. Hiába van tehát diszk titkosítás, innentől kezdve csak hozzáértés és idő kérdése csak a titkosítási kulcsok kinyerése. Ennek tükrében meglep, hogy a cégek nem tolnak fel minden VM-et a felőbe?

Szenti ezt a beszelgetest ne kezdjuk ujra :) Ertem, tudom hidd el... De tessek itt az alkalom - lehet agyalni, segiteni az embernek... Szovegelni elmeleteket gyartani lehet, de a megvalositas nem olyan trivialis mint a mellekelt pelda is mutatja... Nem lehetetlen csak dog nehez... Mint minden mas. Es reszemrol pedig: "I rest my case..."

Ahogy már mások már kifejtették:

1. Aktuális rendszer klónozása, majd a klón megtámadása. A telepített szoftverek ismeretében olyan exploit keresése, amivel root jogosultságot lehet szerezni
3. Exploit futtatása, bejelentkezés root-ként, root jelszó kiütése
4. ???
5. Profit

Ok, nekem csak az szúrt szemet hogy először. :)
Nem használtam még ilyet, lehet túldimenzionálom. Attól függ milyen persze. De ha nem tudom milyen, akkor nem tervezek vele.
Úgy mondanám:
-Először megnézem milyen exploitok vannak, ha tetszik valami, lehet ezt az utat választom.

( tompos v | 2016. 05. 17., k – 19:23 )

Ha a a vmware oldalarol nem megy.
Felterkepezed, hogy mi a helyzet. Ha ilyen a helyzet, akkor gondolom el is vannak hanyagolva. Ha egy semara illeszkednek, keresel egy kozos hibat, betorsz es lecsereled...

Ebben az esetben ez irreleváns, hiszen akinek ez arcméretet jelentene, az a korábbi gazdája a gépeknek, akit nem lehet elérni/előszedni, hogy ugyan már, mi volt a root jelszó ezen a "néhány" gépen...
Egyébként meg ahol az uptime mindenek felett, ott Ksplice, vagy épp KernelCare, oszt' jónapot. (Igen, ez nincs ingyen, de valamit valamiért...)

Nyilván nem ez a legégetőbb probléma, de ez mi a francnak kell?

MYPASSWORD=$(echo EzAzUjPassw0rd)

Illetve mivel nyújt ez többet, mint ez:

MYPASSWORD=EzAzUjPassw0rd

Mert az világos, hogy az első esetben lesz a jelszavam után egy ENTER is, de mivel az ezt követő echo | passwd -nél az echo paraméterét nem raktad idézőjelek közé, kb semmi jelentősége nincs a kéát ENTER-nek - legalábbis nem nagyon látom.
(Persze felfogható subnak is, mert megoldást az eredeti problémára nem tudok.)

( hanzo v | 2016. 05. 17., k – 21:29 )

clone, majd jelszo atir, clone indit grub parameterrel, jelszo atir, clon ujraindit, halokartya kikapcs elotte, regi gep leallit es kozbe clone elindit, max par sec-es kieses lehet, ha ez sok akkor kapjak be nagybol.....

--
http://szolarenergia.hu - A hálózat építést csak elkezdeni lehet, befejezni nem....

( kallaics | 2016. 05. 17., k – 21:39 )

Másik (értsd normál) user és jelszó vagy SSH kulcs nincs esetleg valahol, amivel be lehet menni a gépekre?
Legrosszabb esetben ezeket ki lehet szedni egy snapshotból bootolt gépen és ha van sudo joga, akkor akár működhet is az összes node-on. Reméljük valaki ott felejtette valamelyik node-on a privát kulcsát :)

( wachag | 2016. 05. 17., k – 21:49 )

Hát, VM introspekcióval lehet, hogy lehetne disznólkodni, de még tudtommal erre nincs kiforrott dolog.

( STP | 2016. 05. 17., k – 23:07 )

Főnöknek adni egy kilós kiszerelésű vazelint, hogy ugyan már kezdje el munkálkodni az előző üzemeltetőn, és ne a Te micsodáddal próbálja meg a frissen növekvő csalánt csapkodni.
Plusz adjon már az anyagból egy kicsit az ő főnökének is, mert hogy volt olyan pöcs, és nem fordított kellő figyelmet ennek a kezelésére.

( wauf | 2016. 05. 17., k – 23:10 )

1. VMWare guesten bash inditasa akarmilyen userrel
2. VMWare hoston a /dev/mem-ben rakeresni az 1) pontban inditott process process table entry-jere
3. VMWare hoston atirni az 1) pontban inditott process ownerjet a /dev/mem-ben egy magnesezett tu segitsegevel.
4. Az 1) pontban inditott bash shellben kiadni a "passwd root" magikus inkantaciot
5. ???
6. PROFIT

( STP | 2016. 05. 17., k – 23:10 )

BTW
Van valamilyen account a VM-ekhez?
Local exploit esetleg, amivel root jogot lehet szerezni? :))

( mogorva v | 2016. 05. 18., sze – 08:50 )

Sziasztok,

Köszi a sok hozzászólást. :)

A helyzet erősen vicces, mert senki nem tud semmit, a régi emberek nincsenek sehol és default root login van minden linuxon. Szép, igaz? :)

Annyi könnyítést sikerült találnom, hogy messziről hunyorogva nézve bizonyos viselkedési jellemzők alapján a gépek max. 2-3 csoportba sorolhatók így most az a terv, hogy csoportonként keresek egy-egy random gépet, futtában leklónozom (konzisztencia nem számít), a klónt elbootolom és a klónon fogok john-nal, meg rainbow táblákkal próbálkozni és mondjuk egy hét futás után megnézzük, mi lett.

Egyébként tényleg úgy tudtam (ezek szerint rosszul), hogy pl. wmvaretools-szal bele lehet nyúlni a guest-be, ha nagyon kell.

Thx még1x!

( trey | 2016. 05. 18., sze – 10:16 )

Szia!

Láttam, hogy a HUP-on egy srácnak problémái vannak a VMWare-es gépeivel. Mivel nem vagyok HUP tag, így válaszolni sem tudok neki, úgyhogy kérlek, ha van rá mód majd írd be neki a megoldást ide: http://hup.hu/node/147499

MEGOLDÁS:

1. Készítesz egy snapshot-ot az egyik virtuális gépről (a gép memóriája is legyen benne!).
2. Datastore Browser-ben megkeresed a kérdéses virtuális gépet és letöltöd az előző pontban létrehozott snapshot file-t a gépedre (.vmsn kiterjesztés).
3. Letöltöd a vmss2core programot (https://labs.vmware.com/flings/vmss2core).
4. Admin parancssorból kiadod a következő parancsot: "vmss2core -N SNAPSHOTFILE.vmsn". Ekkor létrejön egy másik vmss.core elnevezésű file a munkakönyvtárban.
5. Letöltöd a strings programot (https://technet.microsoft.com/en-us/sysinternals/strings.aspx).
6. Kiadod a következő parancsot: strings -a vmss.core > snapshotfile-strings.txt
7. Szövegszerkesztőben megnyitod a snapshotfile-strings.txt file-t és rákeresel első körben a passwd, password, psw stringekre, majd ha ez nem segített, akkor végigböngészed a file-t hátha találsz valamit, ami egy root jelszóra emlékeztet.

(Én Win 7-et használok admin gépnek, nyilván linuxos megfelelői is vannak az említett programoknak.)

Köszönöm!

scottie

--
trey @ gépház

És ha talál egy vagy több: 


$6$MHglbglkgLVU5iRi756c/c4IUo7vtOIv786tVV5rkuZRFTZJ/ect4CJkrKjtgLI86zPZboéuOpuOPZvo8674r4xS2u5irou

jellegű stringet egy másolatban, azzal mire megy?

Mondjuk tovább gondolva a dolgot, meg kéne nézni, hogy ssh-val root-ként be lehet- e jelentkezni. Ha igen, akkor a snapshotolt diszken meg kell nézni, hogy a root-nak van-e authorized_keys fájlja. Ha van, és van benne kulcs, akkor "csak" meg kell találni a párját - mondjuk a volt rendszergazda (többi gépen lévő) sima home-jában keresgélve priv/pub kulcspárokat.
Ehhez mondjuk sokat kell snapshot-olni és az így kapott vm-eket átnézni, és elég szigorú megkötés, hogy ssh-val be kell tudni jelentkezni root-ként.

A másik hasznos ötlet lehet a snapshot használatára a sudoers fájl átnyálazása - hátha van benne használható szabály...

> 7. Szövegszerkesztőben megnyitod a snapshotfile-strings.txt file-t és rákeresel első körben a passwd, password, psw stringekre, majd ha ez nem segített, akkor végigböngészed a file-t hátha találsz valamit, ami egy root jelszóra emlékeztet.

Sem a diszken, sem a memoriaban nem fogja megtalalni a jelszot plain textben.

Ha a root jelszót tároló fájl cache-ben benn van, akkor elég lehet talán csak a memóriában átírni a jelszót (mármint a jelszó kripto-hash-jét). És ez pedig valahol a RAM-ban van, tehát a scottie által javasolt módszerrel talán megtalálható, és ha támogatja a VMWare a memóriaterület-felülírást, akkor meg is lehet csinálni, hogy felülvágjuk a jelszó-fájl cache-elt változatát egy ismert jelszó hash-jével. Utána a sudo működik az új jelszóval, és meg lehet változtatni a pass-t hivatalos úton.

( taxy | 2016. 05. 18., sze – 11:14 )

Valahogy (ne kérdezd hogyan) megkeresed a virtual disk fájlban a /bin/bash-nak a setuid-ját vagy valami hasonlót, és valahogy "on the fly" módosítod :)

Forrást meg se néztem, nekem a funkcionalitás beépítésével van bajom. Ugyanis az alapszoftverek egy elég jelentős részéből lehet több-kevesebb macerával shellt futtatni, tehát akkor innentől kezdve ugyanezt a baromságot bele kéne építeni azokba is, különben kb semmi értelme a dolognak. (Azért remélem egy root-ként futtatott ed/ex/vi-ból indított shell nem kezd el nekem valami más júzerré váltani csak azért, hogy engem megvédjen.)

különben kb semmi értelme a dolognak.

De, van. Ha a vi-ra setuidot raksz, és a vi nincs erre felkészítve (értsd: meghagyja azt az állapotot, hogy euid != ruid, nem veszi fel a root jogokat), akkor amint a vi-ból meghívsz egy scriptet, az biztonsági kockázat lenne. Na a bash ezt lekezeli, és ugyanúgy eldobja az extra jogokat, mintha magára a bashra raktad volna a setuidot.

Ergó: kurva jó ez így - bármennyire frusztráló is, hogy nem tudsz setuid bash-t csinálni :D

Vagy kozvetlenul belenyulhat a futo gep /etc/shadow -jaba is:
hash ismertre csereles -> gyorsan login -> hash visszacsere, hogy ne torjenek el az esetleges jelszora epulo automata dolgok (pl. backup, replication, monitoring scriptek (ha van olyan, ami nem kulccsal megy be...))

Kivulrol, read only modon megkeresi, hogy hol kerdeses adatsor, aztan kozvetlen oda dd-z, felmountolas nelkul. (dd seek=...)

Neheziti a dolgot, ha
- softraid van (tobb helyre kell dd-zni, checksumok elromlanak)
- zfs, btrfs (checksumok elromlanak, backup extentrol visszaallitja, vagy read error)
- encrypted block dev... :)

Nincs 1:1 tutorial rá az biztos, de különböző példákból össze lehet rakni elméletben. 


sudo mount vmware-server-flat.vmdk /tmp/test/ -o ro,loop=/dev/loop1,offset=32768 -t ntfs
filefrag -v /tmp/test/etc/shadow
dd ... of=/dev/loop1 ...

Kiindulásnak, aztán rendesen kitesztelni a módszert használat előtt.

A guest gépen meg valahogy ki kell rázni a read cache-ből a dolgokat(user-ként). Na, azt is érdemes előre kipróbálni.

- Csinalsz egy snapshotot, rebootolod init=/bin/bash -sel, remeled, hogy nincs encrypted block dev.

- NEM csereled le a root jelszot, hogy a block device-on ne valtozzon a /etc/shadow helye!

- viszont belenezel a /etc/shadow file-ba, ki copy-pasteled a regi hash-t

- ujrainditod normalisan

- ezutan a host gepen valami ilyesmi:

grep --text --only-matching --byte-offset --fixed-strings "ide-jon-a-regi-hash" ide-jon-a-futo-vm-diszkje

Ez kiirja, hogy melyik byte offszeten kezdodik a kerdeses string.
Konnyen lehet, hogy tobb helyen meg fogja talalni, (mert tobbszor irtak a file-t es a filerendszer mashova tette, vagy amugy is COW a filerendszer (ZFS, btrfs), snapshot (akar LVM), stb.) ez esetben mindenhol bele kell majd nyulni, hogy eltalald a pont jot.

- Ez utan egy ismert jelszobol keszult hashre csereled (ezek a hash-sek egyseges hosszusaguak?) valami ilyesmivel:

echo -n "uj_hash" | dd of=ide-jon-a-futo-vm-diszkje bs=1 seek=ahol_a_grep_megtalalta

- Ezutan urja futtatod a grepet (az uj hash-sel), hogy ugyanott talalja-e meg, nem rontottad-e el. (off by one, soremeles, stb.) Elotte-utana egy darab ki dd-zesevel (bs=1 skip=...) es osszehasonlitasaval ellenorizd esetleg, hogy nem is nyultal-e tul, stb.

- Ha latszolag sikeresen lecserelted, megprobalsz beloginelni.

- talan muxik az ismert jelszo :)

- adsz magadnak bejarast (ssh kulcs), hasht visszacsereled a fentiek miatt, hatha valami epul a regi passwd-re.

Ugye ha tobb blockdevbol all a vm filerendszere (mert fizikai diszkek mentek a vmware ala, vagy iscsi, vagy nbd, stb.), netan pl. zfs/btrfs raid van, az szivasabb, de hasonlo modon lehet parhuzamosan is, ha mar begyakoroltad/scriptesitetted a dolgot.
Ha raid checksum vagy fs checksum hiba miatt nem megy a dolog, na az mar kemenyebb dio, az encrypted block dev meg meg kemenyebb...

- ha mar begyakoroltad/scriptesitetted a dolgot mehet elesben is. :)

brutalisan bele dd-z a megfelelo helyre, nem ismerve se embert se istent

viszont -ahogy masok irtak is- a futo oprendszer bekesseli a shadow file-t, ugyhogy tenyleg elsore kell sikerulnie a loginnek (vagy ismeretlen ideju varakozas...)

A dd opcioi kozul kifelejtettem a conv=notrunc,sync -ot, szoval valahogy igy:

echo -n "uj_hash" | dd of=ide-jon-a-futo-vm-diszkje bs=1 seek=ahol_a_grep_megtalalta conv=notrunc,sync

( _Franko_ v | 2016. 05. 18., sze – 12:49 )

Ööö... izé... biztos fel kell ezt vállalnod? Szép, meg jó, meg minden, csak tele van olyan buktatóval, amiért a te farkadból fognak levágni pár centit, ahelyett, hogy az előző banda és/vagy a főnökeik farkából vágtak volna le.

Eszkaláld a problémát, vegyél egy kávét, dőlj hátra és élvezd a műsort...

( eff | 2016. 05. 18., sze – 13:55 )

Diszk felcsatolása másik VM-ben (feltéve, hogy nem encrypted a disk/fs), és chroot után passwd?
Nem tudom VMWare enged-e olyat, hogy egy disk image-et több géphez is csatolhass.

KVM-es futó gép qcow2 "diskjét" már csatoltam fel a hoston minden gond nélkül és simán lehetett írni/olvasni mindent, ami kellett (okát inkább ne firtassuk, de nem jelszó miatt :) ).
Gyanítom a VMWare-t is fel lehet valahogy.
Ha felcsatolta, akkor gány megoldásként egy másik gépen lévő passwd hash-t be lehetne tolni, aztán meg belépni. Így a root jelszót sem vágja haza, de mégis valahogy belépett rájuk. Nyilván nem árt egy sudo jogot is adni az újdonsült felhasználónak. De ha nem fél attól, hogy eltörik valami a root pass cseréje miatt, akkor lehet azt is cserélni közvetlenül.
Előtte egy mentés nem árthat a gépről.

szerk.: http://www.commandlinefu.com/commands/view/12554/mount-a-vmware-virtual…

működik, nekem is ez ugrott be elsőre, de mivel "fontos, leállíthatatlan" gépekről van szó, mégsem kockáztatnám meg, mert ugye a shared lock hiánya miatt a legnagyobb óvatosság mellett is okoz némi fájlrendszer sérülést, amit ugyan a következő reboot-nál az fsck megold, de éles rendszeren akkor is csak végső elkeseredésemben tenném.

persze, ha nagyot módosítasz rajta pl egy fsck lefuttatásával a második csatoláson vagy egyéb ilyen dőreséggel. De ha minimalistán mountolod, és egyetlen, általában statikus fájlban, a fájl hosszát nem növelő módon változtatsz valamit (= jó eséllyel nem módosít inode táblát), majd lemountolod, akkor nem sérül (jelentősen). Ez meg elég egy shadow vagy sudoers változtatáshoz.
(perverzek ugyanezt lejátszhatják hexa editorral a raw device-on és akkor tuti csak az a pár byte változik)

Továbbra is figyelmeztetés, ez nem megoldási javaslat!

A /etc/shadow esetleges sérülését nem biztos, hogy díjazni fogja... És ha az fsck miatt single módot akar suloginnal, akkor erősen ott lesz a kolléga, mint a mádi honpolgár... Bár gyakorlatilag most is ez a helyzet, csak az fs látszólag rendben van. (Volt szerencsém olyan szerverhez, ami sok-sok ideje futott rendesen, aztán a reboot során olyan hátast dobott az fsck-n, hogy öröm volt nézni...

Az init=/bin/bash ezen nem segít?

Gőzöm nincs mibe teszi a vmware a lemezképeket, de ha ilyen autoexpand cucc akkor lehet a hex editor se életbiztosítás.

Az egyetemen anno egyik srác megjátszotta ezt (a core ment az /etc/passwd-be) nem is engedett be utána senkit (egy darabig őt se gép közelébe). :D

Ha a / rendben van, akkor segíthet,de ha a / van (nagyon) elgyakva, akkor csak a recovery cd/dvd jöhet számításba...
Lehet hexa editorral, meg mindenféle gányolással próbálkozni - egyetemen, laborban, kísérleti/teszt rendszerek esetében. Itt viszont nem erről van szó, hanem egy rakat éles, 7x24-es kiszolgálást végző virtuális gépről... Ilyen környezetben nem igazán célravezető azoknak a módszereknek a felfedezése, ahogy _nem_ oldható meg a probléma.

De ha minimalistán mountolod

Persze. Csak nehéz úgy mountolni read-write-ra, hogy pl. a journalt ne pörgesse vissza - ergó tutkó biztosan bele fog barmolni a fájlrendszerbe.

A hex editoron kívül nem látok már megoldást a feladatra - és még úgy sem biztos, hogy nem sikerült elbaszni.

( flatline | 2016. 05. 18., sze – 14:41 )

Ahogy mondani szokás, innen szép nyerni.

( apostroph3 | 2016. 05. 18., sze – 19:28 )

csak van valami dokumentáció arról a hálózatról, az admin gépen nem?

ha meg nincs, vagy akinek tudnia kellene, hogy hol van az sem tudja, akkor te ne izgasd magad emiatt, próbáld meg egy vélhetőleg kevésbé káros időpontban újraindítgatni a gépeket, elvégre te vagy a gazda, az van amit te mondasz, a többiek meg csak ugatják a dolgot, különben már megcsinálták volna.

ha ez így nem jó, akkor csinálják meg ők maguk :)

és nézz rájuk jó mogorván!! :)

( bazso | 2016. 05. 18., sze – 21:47 )

Hátha:
gép lemásolása, sudoers fájl megnézése, nevesített, sudo joggal rendelkező felhasználók megkeresése, lefizetése/megfenyegetése. Gondolom nem egyetlen üzemeltetője volt 100 gépnek aki ráadásul root-ként lépett be.

( turul16 v | 2016. 05. 19., cs – 07:52 )

Sima user account van-e a gepekhez ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( hokuszpk | 2016. 05. 20., p – 08:19 )

nem vagyok egy vmware expert, de elso korben a jelszoval nemnagyon foglalkoznek.
Leklonoznam, a gepet es a klonozott gepen eloszor a /root/.ssh/authorized keys filet neznem meg.
ha van kulcs, akkor az eleg hosszu ahhoz, hogy egyertelmuen ra lehessen keresni, es egy ugyanolyan hosszu kulcsra kicsrelni valami diskeditorral.
tobben irtak, hogy a vmware imaget fel lehet mountolni, akkor plane elsore a kulccsret probalnam meg.

ha meg megis jelszofejtes a vege, akkor osszeszedem a kornyeken levo videokartyakat, es oclhashcat.

( Finder | 2016. 05. 23., h – 00:31 )

> [..] hogy a gépek rebootja nélkül [..]

Ez miert kovetelmeny?
Tudod, meg lehet valaszolni a kerdest, vagy meg lehet oldani a problemat... :)