Hozzon létre kifizetéseket a metasploit számára, és bejutjon benne

A kizsákmányolás fejlesztése során valószínűleg létre kell hoznia a kizsákmányolás során használt kódot. Metasploitpayloads generálható az msfconsole-ból. Ha bizonyos terhelést használsz. A Metasploit hozzáadja a parancsok "generálását", "pry" és "reload" parancsokat. A Generate lesz a cikk fő tárgya, a Metasploit használatának feltárása.

Kezdjük azzal, hogy megnézzük a "ganerate" parancs különböző lehetőségeit, és futtasd a "-h" -nel.

A shell kód létrehozása nélkül, egyszerűen adja ki a "generate" parancsot.

Természetesen elég kicsi a valószínűsége annak, hogy hibakódot hoznak létre hibakódok nélkül. Gyakran előfordul, hogy a célgéptől függően rossz karaktereket és specifikus kódolókat használnak.

A fenti kódpélda szinte univerzális rossz karaktert tartalmaz, null bájtot (\ x00). A rendelkezésre álló kizsákmányok némelyike ​​lehetővé teszi annak használatát, de nem sok. Hagyjuk ugyanazt a shell kódot létrehozni, csak ezúttal megadjuk a Metasploit utasításait a nem kívánt bájt eltávolításához.

Ennek elérése érdekében a "ganerate" parancsot és a "-b" kifejezést a mellékelt bájtokkal állítjuk be, amelyeket meg akarunk tagadni a generációs folyamat során.

Ha megnézed ezt a kódot, akkor könnyedén megnézheted ezt az előzőleg létrehozott shellhez képest. nulla bájt sikeresen törölve. Ez nulla byte-os szabad teret enged. A termelésben bekövetkezett kényszerű változásokhoz kapcsolódó egyéb jelentős különbségeket is látunk.

Az egyik különbség a shell kódok közös byte-mérete. A korábbi integrációban a méret 328 bájt volt. az új héjban 27 bájt nagyobb.

A generálás során a kezdeti null bájtokat, vagy a kódban hasznos adatokat ki kell cserélni vagy kódolni kell, hogy csak a hozzá tartozó shell shell memóriájába kerüljenek.

Egy másik fontos változás az alkalmazott kódoló hozzáadása. Alapértelmezés szerint a Metasploit kiválasztja a legjobb kódolót a feladat elvégzéséhez. A kódoló felelős a "-b" használatakor megadott nemkívánatos karakterek (többek között) eltávolításáért. A kódolókat később részletesebben tárgyaljuk.

A nem kívánt karakterek megadása során a keret a legjobb kódolót fogja használni. Az x86 / shikata_ga_nai kódolót használtuk. amikor a nulla bájt korlátozott volt a kód generálása során. Ha még néhány nem kívánt karaktert adunk hozzá, akkor egy másik karaktert használhatunk ugyanazon feladat végrehajtásához. Adjunk még néhány bájtot a listára, és nézzük meg, mi történik.

Látjuk, hogy a kódoló különbözik attól, amely korábban sikeresen törölte a nem kívánt bájtokat. Shikata_ga_nai. valószínűleg nem tudta a terhelést kódolni a byte limitek listáján. Fnstenv_mov azonban sikerült elérnie ezt.

A Payload generálása sikertelen

Az a képesség, hogy kódkódot generál bizonyos karakterek használata nélkül, egyike annak a nagy lehetőségnek, amelyet ez a keretek nyújtanak. Ez nem jelenti azt, hogy korlátlan.

A kódoló által korlátozott túl sok bájt nem végezhető el. Ilyenkor a Metasploit a következő üzenetet tükrözi.

Ez hasonló ahhoz, hogyan távolítsunk el sok betűt az ábécéből, és kérjünk valakit, hogy írjon egy teljes mondatot. Néha nem teheti meg.

Enkóder használata a hasznos terhek létrehozása közben

Amint korábban említettük, a keretrendszer kiválasztja a legjobb elérhető kódolót a hasznos terhelés generálásakor. Vannak azonban olyan idők, amikor bizonyos típusú kódolót kell használni, függetlenül attól, hogy mit gondol a Metasploit. Képzeld el, hogy egy kizsákmányolás csak akkor lesz sikeres, ha nem tartalmaz alfanumerikus karaktereket. A "shikata_ga_nai" kódoló ebben az esetben haszontalan, mivel elég sok szimbólumot használ a kódoláshoz. Miután megnéztük a kódolók listáját, látjuk, hogy az "x86 / nonalpha" kódoló jelen van.

Tegyük fel újra a jó teljesítményt, de ezúttal mondjuk, hogy a keret az 'nonalpha' kódolót használja. Ezt a '-e' és az ezt követő kódoló nevével kapcsoljuk, az alábbi listán látható módon.

Ha minden a terv szerint ment, a hasznos tartalom nem tartalmaz alfanumerikus karaktereket. De óvatosnak kell lennünk, ha más kódolót használunk, mint az alapértelmezett. Általában ez nagyobb hasznot hoz. Például az, amely kiadta ezt a kódolót, sokkal több, mint az előző példákban.

A következő opció a listában a -f kapcsoló. Ez lehetővé teszi számunkra, hogy a generált hasznos tartalom kimenetét mentse a fájlra ahelyett, hogy megjelenítené azt a képernyőn. Mint mindig, követi a "generál" parancsot a fájl elérési útjával.

A "cat" parancs segítségével láthatja a fájlt tartalmazó mentett adatot. Amint látjuk, egynél több opciót is használhatunk shell kód létrehozásakor.

Hasznos mennyiség létrehozása több szálon

Az opciós listán a következő váltás az '-i' iterációs kapcsoló. Dióhéjban, mondja a keret. hány kódolást kell eljuttatnia, mielőtt elkészítené a végső hasznos terhet. Ennek egyik oka lehet lopakodó vagy vírusellenes kijátszás. Részletesebb víruskereső kijátszást fogok fontolóra venni az MSFU egy másik részében.

Tehát hasonlítsuk össze az 1 iterációval generált shell payload értéket, összehasonlítva ugyanarra a shell kódra, 2 iterációval.

Összehasonlítva a két kimenetet, látjuk a hasznos teljesítményünk második iterációjának nyilvánvaló hatását. Először is, a bájtok mérete nagyobb, mint az első. Minél több iteráció van a hasznos terhelésnél. annál több lesz. A másodikban összehasonlítjuk a bájtok következtetéseit, és látjuk, hogy azok is különböznek egymástól. Ez a második iterációnak vagy a második kódolásnak köszönhető. Egyszer egyszer kódolja a hasznos terheket, majd visszaküldi a terhelést és újra kódolja. Vegyük a kódot, és nézzük meg, mi a különbség öt iterációban.

A változások jelentősek az összes korábbi következtetéshez képest. Ez valamivel nagyobb, és nincsenek hasonló bájtok a közelben. Ami elméletben a legkevésbé érzékeny terhelésünknek ez a verziója.

Sok időt töltöttünk a shell kód létrehozásáról kezdettől fogva az alapértelmezett értéktől. Kötés esetén a héj alapértelmezés szerint a 4444 portra figyel. Gyakran ezt módosítani kell. Ezt a "-o" kapcsolóval megtehetjük, mielőtt megváltoztatnánk az értéket. Lássuk, milyen lehetőségeket tudunk változtatni erre a terhelésre. Az msfconsole-ból adjuk meg a "show options" parancsot.

Alapértelmezés szerint a héjunk a "4444" porton hallgat és a "folyamat" funkciót adja ki. Ezt a portot "1234" -re változtatjuk, és a "seh" funkciót a -o paranccsal adjuk ki. Szintaxis változó = az egyes opciók között vesszővel elválasztott érték. Ebben az esetben mindkét port figyeli, és a funkció kimenetét a következő "LPORT = 1234, EXITFUNC = seh" szintaxissal változtatja.

A hasznos teret NOP Sled használatával generálják

Végezetül vessünk egy pillantást a NOP szánhossz és a kimeneti formátum beállításaira. A payloadok alapértelmezés szerinti generálásakor a kimeneti formátum a "ruby" -ben van megadva. Bár a rubin nyelv rendkívül erős és népszerű, nem minden kód. Lehetőségünk van arra, hogy jelentjük a keretet. hogy adathordozónk különböző kódolási formátumokban, mint a Perl. C és Java. például. Add hozzá a NOP szán is az elején, amikor generál shell kódot.

Először nézzük meg a különböző kimeneti formátumokat, és nézzük meg, hogyan használjuk a -t kapcsolót. Mint minden más lehetőséghez, mindössze annyit kell tennie, hogy megadja a következő formátumú kapcsolót, amint azt a súgó menü mutatja.

Az NOP szán hozzáadása (nincs művelet vagy következő művelet) a '-s' kapcsolóval történik a NOP-ok száma előtt. Ez hozzáadja a szánját a rakomány kezdetéhez. Ne feledje, hogy minél több szán van, annál inkább a shell kód lesz. Ezért a 14 NOP hozzáadása 14 bájtot ad a teljes mérethez.

Sárga színben, a NOP szánunk kiemelkedik a hasznos teher kezdetekor. Ha összehasonlítjuk a következő sorokat a fenti shell kóddal, látjuk, hogy pontosan ugyanazok. Összességében, ahogy várták, 14 bájt nagyobb lett.