Remote code execution (RCE), explained: mi ez és hogyan lehet megakadályozni

a Remote code execution (RCE) a szoftverbiztonsági hibák/sebezhetőségek egyik osztálya. Az RCE biztonsági rései lehetővé teszik a rosszindulatú szereplők számára, hogy bármilyen választott kódot végrehajtsanak egy távoli gépen LAN-on, WAN-on vagy interneten keresztül. Az RCE az önkényes kódfuttatási (Ace) sebezhetőségek szélesebb osztályába tartozik. Az internet egyre mindenütt, bár, RCE sebezhetőségek hatása gyorsan növekszik. Tehát az RCEs valószínűleg az ACE sebezhetőség legfontosabb fajtája.

mivel ez a helyzet, részletesebben meg akartuk vizsgálni az RCE különféle sérülékenységeit és a lehetséges ellenintézkedéseket.

RCE származás szerinti osztályozás

az ismert RCE sebezhetőségek többségének, ha nem mindegyikének, kevés oka van.

dinamikus kódfuttatás

a dinamikus kódfuttatás általában a leggyakoribb támadási vektor, amely RCE-hez vezet. A legtöbb programozási nyelvnek van valamilyen módja a kód generálására és a helyszínen történő végrehajtására. Ez egy nagyon erős koncepció, amely segít megoldani sok összetett problémát. Egy rosszindulatú harmadik fél azonban könnyen visszaélhet vele az RCE képességek megszerzése érdekében.

a futásidőben generált kód gyakran valamilyen felhasználói bevitelen alapul. Gyakrabban, mint nem, a kód valamilyen formában tartalmazza ezt a bemenetet. Egy rosszindulatú szereplő, felismerve, hogy a dinamikus kódgenerálás egy adott bemenetet fog használni, érvényes kódot adhat bemenetként az alkalmazás megtámadásához. Ha a felhasználói bemenetek nincsenek ellenőrizve, akkor ez a kód a célgépen kerül végrehajtásra.

Általánosságban elmondható, hogy a dinamikus kódfuttatás az RCE két fő osztályát okozza: közvetlen és közvetett.

közvetlen

közvetlen dinamikus kódfuttatás esetén a rosszindulatú szereplő tisztában van azzal, hogy bemenetüket kódgeneráláshoz használják.

közvetett

a közvetett eset ismét a dinamikus kódgeneráláshoz vezet, beleértve a felhasználói bemeneteket is. A felhasználói bevitel azonban egy vagy több rétegen halad át. Néhány réteg még átalakíthatja ezt a bemenetet, mielőtt dinamikus kódgenerálással végződne. A dinamikus kódgenerálás is mellékhatás lehet, nem pedig a bemenet elsődleges használata. Mint ilyen, a bemenetet biztosító felhasználó számára nem igazán nyilvánvaló, hogy a bemenetet építőelemként használják egy távoli gépen végrehajtandó kódrészletben.

Deszerializáció

a Deszerializáció nagyon jó példa erre a forgatókönyvre. Látszólag nem dinamikus kód generálása történhet deserialization. Valójában ez a helyzet, ha a sorosított objektum csak primitív típusú adatmezőket vagy más ilyen jellegű objektumokat tartalmaz. A dolgok azonban bonyolultabbá válnak, ha egy objektum metódusait/funkcióit sorosítják. A dezerializáció ekkor általában magában foglalja a dinamikus kódgenerálás valamilyen formáját.

azt gondolhatnánk, hogy a dinamikus nyelvek az egyetlen hely, ahol a függvénysorosításnak van értelme. A probléma akkor korlátozott hatókörű lesz. De ez egy hasznos forgatókönyv statikus nyelvekben is. Ez valamivel nehezebb elérni egy statikus nyelv, de messze nem lehetetlen.

a megvalósítás gyakran deserializációval generált proxyobjektumokból/funkciókból áll. Objektumok / funkciók generálása futásidőben a dinamikus kódgenerálás esete. Tehát, ha a deszerializálandó adatok egy távoli gép kéréséből származnak, egy rosszindulatú szereplő módosíthatja azokat. Gondosan kialakított sorosított kódrészletek injektálhatók, amelyek becsapják a dinamikus kódgenerálást, hogy végrehajtsák őket, amikor a deszerializáció részeként hivatkoznak rájuk.

Memóriabiztonság

az RCE biztonsági réseinek másik oka a memória biztonsága. A memóriabiztonság azt jelenti, hogy megakadályozzuk, hogy a kód hozzáférjen a memória azon részeihez, amelyeket nem inicializált vagy nem kapott bemenetként. Intuitív módon arra számíthat, hogy a memória biztonságának hiánya jogosulatlan adathozzáférést eredményez. Az operációs rendszer és az alapul szolgáló hardver azonban memóriát használ a tényleges futtatható kód tárolására. A kódfuttatással kapcsolatos metaadatok a memóriában is tárolódnak. Az ilyen típusú memóriához való hozzáférés ACE-t és esetleg RCE-t eredményezhet. Tehát mi a fő oka a memória biztonsági kérdéseinek?

szoftvertervezési hibák

a szoftvertervezési hibák a memóriabiztonsági sebezhetőség egyik típusa, ahol valamilyen mögöttes komponens tervezési hibája van. Gyakrabban, mint nem, ez egy fordító, tolmács vagy virtuális gép, vagy potenciálisan az operációs rendszer kernele vagy könyvtárai. Számos különböző hiba tartozik ebbe az osztályba. Részletesebben megvizsgáljuk, Mi vitathatatlanul a leggyakoribb.

Puffertúlcsordulás vagy puffertúlcsordulás

a Puffertúlcsordulás (más néven puffertúlcsordulás) meglehetősen egyszerű és jól ismert módszer a memória biztonságának megsértésére. Ez kihasználja a tervezési hiba, vagy egy hiba, hogy írjon a memória sejtek, amelyek követik a tényleges végén egy memória puffer. Maga a puffer visszatér egy legitim hívásból a nyilvános API-ba. A puffer azonban csak kiindulási pontként szolgál valamely objektum vagy programszámláló privát mező/tag értékeinek fizikai memóriacímeinek kiszámításához. A pufferhez viszonyított helyzetük vagy jól ismert, vagy kitalálható. A kód kutatása, ha rendelkezésre áll, vagy a program futtatásának hibakeresése futás közben segíthet a rosszindulatú szereplőknek relatív pozíciók megszerzésében.

tehát a puffertúlcsordulás lehetővé teszi a memória módosítását, amelynek tervezéskor elérhetetlennek kell lennie. Előfordulhat, hogy a puffer egy másik gép címterében található, és egy távoli API meghívásával módosítható. Ez lehetővé teszi a hozzáférést a távoli gép memóriájához. Nyilvánvaló, hogy az ilyen típusú hozzáférés használatának különféle módjai vannak az RCE műszerezésében. Az általános feltételezés az, hogy ha puffertúlcsordulási sebezhetőség létezik, akkor RCE lehetséges. Tehát a kódtulajdonosoknak javítaniuk kell a puffertúlcsordulásokat ASAP, jóval a tényleges RCE támadás megjelenése előtt.

hatókör

gyakrabban, mint nem, a puffertúlcsordulás a C/C++ kódot célozza meg, mivel ezek a nyelvek nem rendelkeznek beépített pufferméret-ellenőrzéssel. Sok más népszerű keretrendszer és technológia végül a c / c++ könyvtárakat használja mélyen a felszín alatt, ami automatikusan sebezhetővé teszi őket az ilyen típusú támadásokkal szemben.

csomópont.js egy jó példa erre, mivel amellett, hogy alapul C / C++, JavaScript runtime is lehetővé teszi a natív C / C++ kiegészítőket. Emiatt a támadó gondosan elkészítheti a kéréseket egy csomópontra.a JS server Puffertúlcsordulást okoz, így módosítja az érintett gép rendszermemóriáját, tetszőleges kód végrehajtását okozva.

hardver tervezési hibák

érdekes módon a memória biztonsági megsértése a hardver biztonsági tervezési hibái miatt is előfordulhat. Bár kevésbé gyakori és nehezebb megtalálni, az ilyen sebezhetőségek általában rendkívül nagy hatással vannak.

az RCE támadások eltérítése

bár minden RCE támadás kimenetele azonos a kódot végrehajtó támadó szempontjából, a támadási vektorok nagyon eltérőek. Mindegyikük blokkolása jelentős erőfeszítéseket igényel. Sőt, az erőfeszítés együtt növekszik a technológiai veremmel. Az ebben a bejegyzésben leírt összes támadási vektor technológia-agnosztikus. Minden megvalósítás technológiaspecifikus, de a védelmi mechanizmusok is.

tehát a hagyományos időtakarékos megközelítés a gyanús tartalom hálózati forgalmának figyelése, ahelyett, hogy az egyes végpontokat a saját technológiájával figyelné. A webalkalmazások tűzfala (WAF) általában elvégzi ezt a feladatot. Bár ez időt takarít meg, ennek is ára van—a WAF a hálózati teljesítmény szűk keresztmetszete, és hiányzik az összes rendelkezésre álló háttérinformáció a tényleges végponton vagy az alkalmazás és a felhasználói szinten. Ezért a WAF forgalmi elemzése soha nem lehet tökéletes. A heurisztika teljes adatok nélkül elkerülhetetlen, így vagy nem minden fenyegetés jelenik meg, vagy hamis pozitív eredmények merülnek fel, vagy leggyakrabban mindkettő.

mozgó belül az app: Az sqreen megközelítése

az Sqreen ezeket a WAF-hiányosságokat kezeli anélkül, hogy növelné a végfelhasználó fejlesztési költségeit az alkalmazáson belüli láthatóság mozgatásával, teljesebb védelmet nyújtva a technológia-specifikus RASP és az alkalmazáson belüli WAF segítségével. Az Sqreen RASP és WAF a tényleges webes alkalmazáson, API-n vagy mikroszolgáltatáson belül fut, amely hálózati forgalmat fogad. Nem igényel semmilyen kód módosítását, bár. Az egyes technológiákra jellemző műszerezési pontokat használ (például JVM API Java-hoz, v8 API csomóponthoz.js, stb.) a kód módosítása futásidejű végrehajtás előtt. Így képes nyomon követni és módosítani a rendszer és a hálózati eseményeket, miközben teljes kontextusban van minden, ami az alkalmazáson belül történik.

így az Sqreen képes felismerni, hogy az alkalmazás ismert memóriabiztonsági problémákkal rendelkező összetevőket használ. Azt is érzékeli a tényleges felhasználói bemenetek teszik, hogy a dinamikus kódfuttatási eseményeket. Természetesen ez egy kiváló megközelítés az RCEs észlelésére és megelőzésére, mint egy hagyományos WAF, amely csak a hálózati forgalomhoz fér hozzá.

csomagolás

nyilvánvaló, hogy az RCE nagyon erős támadási vektor. De szerencsére meg lehet védeni magát az RCE támadásokkal szemben is. A fenti információk valóban segíthetnek a védelmi stratégia kialakításában. Ha más támadási vektorok és részletek érdekelnek, nézd meg az SQL injection, XXE és LFI korábbi bejegyzéseinket.