Biztonság a homályon keresztül az emberi tevékenység különböző területein a biztonság biztosítására használt elv . Az alapötlet az, hogy elrejtse egy rendszer vagy megvalósítás belső elemeit a biztonság érdekében.
A „biztonság az ismeretlenségen keresztül” rendszerben előfordulhatnak meglévő vagy feltételezett sebezhetőségek , de tulajdonosai vagy fejlesztői úgy vélik, hogy ha a hibák nem ismertek, akkor a támadó nem fogja tudni észlelni azokat. A rendszer a rejtettségen keresztüli biztonságot is használhatja a rendszervédelem egyik rétegeként, mivel ez időt ad a rendszerfejlesztőknek a talált sérülékenység kijavítására, míg a termékek és verziók nyilvánosságra hozatala a termékekben felfedezett sebezhetőségek kihasználásának fő célpontjává teszi őket. verziók. A támadó első lépése általában az információgyűjtés, ezt a feladatot megnehezíti a biztonság homályos használata.
Az ismeretlenségen keresztüli biztonságról szóló hivatalos szakirodalom meglehetősen ritka. A biztonságtechnikai könyvek az 1883-as Kerckhoff-elvre hivatkoznak, ha egyáltalán utalnak valamire.
A jog területén Peter Swire írt a kompromisszumról a „biztonság a homályon keresztül csak illúzió” és a katonaság azon nézete között, hogy „a pletykák elsüllyesztik a hajókat”, és hogy a verseny hogyan befolyásolja a közzétételi ösztönzőket.
A homályon keresztüli biztonság elve mindennapos volt a kriptográfiai munkában azokban az időkben, amikor lényegében minden jól informált kriptográfus a nemzeti hírszerző ügynökségeknél, például a Nemzetbiztonsági Ügynökségnél dolgozott . A kriptográfusok manapság gyakran dolgoznak egyetemeken, ahol a kutatók sok vagy akár az összes eredményüket publikálják, és nyilvánosan tesztelik mások terveit, vagy a magánszektorban, ahol az eredményeket gyakrabban szabályozzák a szabadalmak és a szerzői jogok, mint a titoktartás, így az elv egy részét elvesztette. korábbi népszerűsége. Például a PGP-t forráskódként adják ki, és általában (ha helyesen használják) katonai szintű titkosítási rendszernek tekintik.
Érveket mutatunk be az elv alkalmazása mellett. Bár rossz ötlet olyan rendszervédelmet létrehozni, amely kizárólag az ismeretlenségen keresztüli biztonság elvén alapul, ennek az elvnek a használata a rendszer egyes részleteinek titokban tartása érdekében okos taktika lehet egy réteges biztonsági rendszeren belül. Például, amikor a rendszer biztonsági rését fedezik fel annak létrehozói, az ismeretlenség általi biztonság átmeneti akadályt jelenthet a támadók számára, amíg a biztonsági rést ki nem javítják. Ebben az esetben az elv alkalmazásának célja, hogy rövid távon csökkentse a rendszer fő összetevőiben lévő sérülékenység kihasználásának kockázatát.
Vegyünk egy olyan számítógépes hálózatot, amely ismert biztonsági rést tartalmaz. Mivel a támadónak nincs információja a rendszer adott eszközéről, el kell döntenie, hogy használja-e ezt a biztonsági rést vagy sem. Ha a rendszer úgy van beállítva, hogy észlelje ezt a sérülékenységet, akkor észleli, hogy támadás alatt áll, és válaszolhat, vagy a rendszer lezárásával, amíg a rendszergazdáknak nem lesz lehetőségük válaszolni, vagy a támadó támadásának figyelésével és nyomon követésével, vagy a támadó leválasztásával. . Az elv alkalmazásának ebben a helyzetben az a lényege, hogy a támadó nem tudja gyorsan megszerezni a szükséges információkat a rendszerről ahhoz, hogy határozott döntést tudjon hozni a sérülékenység kihasználása során felmerülő blokkolási kockázat és az esetleges jutalom arányáról. egy sikeres támadásról. Emellett a rendszer felépítésére vonatkozó szükséges információk hiánya miatt nem tudja egyértelműen kiválasztani a rendszer azon részét, amelyet elsősorban támadni kell.
Az elv használatának másik stratégiája magában foglalja a sebezhetőségek kettős rétegének meglétét, amelyek mindkettőt titokban tartják. A rendszer készítői ugyanakkor lehetővé teszik az egyik sebezhetőség „kiszivárgását”. Az ötlet az, hogy hamis bizonyosságot adjon a támadónak arról, hogy a védelmet legyőzték, és ő nyert. Használható például csali részeként (a kifejezés orosz megfelelője az „élőcsali horgászat”).
A homályon keresztüli biztonság elve elleni érvek Kerckhoffs elvéhez nyúlnak vissza, amelyet Auguste Kerckhoffs 1883-ban terjesztett elő . Ez az elv kimondja, hogy a kriptográfiai rendszer kialakítása nem követelhet meg titoktartást, és nem okozhat kellemetlenséget, ha az ellenség kezébe kerül. A fejlesztőknek feltételezniük kell, hogy a biztonsági rendszer teljes felépítését ismerik a támadók, kivéve a kriptográfiai kulcsokat (a kriptográfiai rendszer biztonsága teljes mértékben a kriptográfiai kulcsban rejlik). 1940-ben Claude Shannon úgy fogalmazta meg ezt az elvet, hogy "az ellenség ismeri a rendszert".
Minél több lehetséges kompromittációs pontot tartalmaz a rendszer, annál valószínűbb, hogy ezen pontok valamelyikén létezik vagy kerül kidolgozásra támadási stratégia. Azok a rendszerek, amelyek szerkezeti vagy működési titkot tartalmaznak, amelyek egyben lehetséges kompromittációs pontok is, kevésbé biztonságosak, mint az ilyen pontok nélküli hasonló rendszerek, ha a projekt szerkezetének vagy működési módjának feltárása miatti sebezhetőség eléréséhez szükséges erőfeszítés, valamint a kihasználja ezt a biztonsági rést, kevesebb erőfeszítést igényel a titkos kulcs beszerzése. A rendszerbiztonsági szint a biztonsági rés kihasználásához szükséges erőfeszítésekre csökken.
Például, ha valaki tartalékkulcsot tart a szőnyeg alatt, ha az ajtók kívülről záródnak, akkor az ismeretlenségen keresztül a biztonságra hagyatkozik. Az elméleti biztonsági rés az, hogy valaki behatolhat a házba, ha ezzel a pótkulccsal kinyitja az ajtót. Ezenkívül, mivel a betörők gyakran ismerik a tervezett búvóhelyeket, a lakás tulajdonosa nagyobb betörésveszélynek van kitéve, ha elrejti a kulcsot, mivel a kulcs megtalálásához szükséges erőfeszítés valószínűleg kevesebb, mint a behatolás (pl. betöréssel) más módon, például üvegen keresztül. A tulajdonos egy sérülékenységet – azt a tényt, hogy a beviteli kulcs a szőnyeg alatt tárolják – beépítette a rendszerbe, amely nagyon könnyen kitalálható és kihasználható.
Korábban számos belső részleteket rejtő szoftveralgoritmus vagy rendszer tette nyilvánossá ezeket a belső részleteket. Véletlen nyilvánosságra hozatalra több alkalommal is sor került, például a híres GSM -ügyben a titkosítással kapcsolatos bizalmas dokumentációt a szokásos titoktartási követelmények előírása nélkül továbbították a Bradfordi Egyetemre [1] . Ráadásul a szoftverek sebezhetőségeit még akkor is felfedezték és kihasználták, ha a belső részletek titokban maradtak. Összességében ezek és más példák azt mutatják, hogy nehéz vagy nem hatékony a rendszerek és algoritmusok részleteit titokban tartani.
A homályon keresztüli biztonság nem tekinthető a rendszerbiztonság megfelelő mérnöki megközelítésének, mivel ellentétes a „KISS” elvvel . Az Országos Szabványügyi és Technológiai Intézet kifejezetten azt javasolja, hogy legfeljebb egy dokumentumban használjon biztonságot az ismeretlenségen keresztül. A NIST szerint "egy biztonsági rendszer nem függhet egy implementáció vagy összetevői titkosságától" [2] .
Általános konszenzus van még azok között is, akik a biztonságot a homályon keresztül hirdetik, hogy a „biztonság az ismeretlenségen keresztül” elvét soha nem szabad elsődleges biztonsági intézkedésként használni. Ez a legjobb esetben egy másodlagos intézkedés, és a kétértelműség felfedése nem vezethet kompromisszumhoz .
Az elv használatának értéke nyílt vagy zárt szoftverek létrehozásakor nagyon eltérő és kétértelmű. Fontolja meg a nyílt forráskódú szoftverek létrehozásának folyamatát. A fejlesztőket leggyakrabban jobban érdekli új kód létrehozása, mint a meglévő kódok sebezhetőségeinek elemzése. Mivel a nyílt forráskódú szoftverek létrehozása önkéntes erőfeszítés, általában kisebb hangsúlyt kap a biztonság, mintha a szerzők egyik feladata a program biztonságának elemzése lenne. Másrészt létezik Linus törvénye , amely szerint "elég szemmel a bogarak a felszínre úsznak", az algoritmusok és protokollok fokozott biztonságát javasolja, ennek leírását közzéteszik. Többen láthatják az ilyen algoritmusok részleteit, azonosíthatják a hibákat és hamarabb kijavíthatják azokat. E nézet támogatói úgy vélik, hogy a kompromisszum következményeinek gyakorisága és súlyossága kisebb lesz, mint a védett vagy titkos szoftverek esetében. Mindebből arra a következtetésre juthatunk, hogy nyílt forráskódú szoftverek készítése esetén a biztonság közvetlenül függ a program népszerűségétől, vagyis minél nagyobb a népszerűség, minél több önkéntes elemzi a programkódot, és annál nagyobb a valószínűsége a sebezhetőség megtalálásának. benne. Ennek alátámasztására hozunk egy példát arra, hogy a Linux forráskódban 0,17 hiba jut ezer sor forráskódra [3] , míg a zárt kereskedelmi szoftvereknél átlagosan 20-30 hiba van 1000 sornyi forráskódon.
Ami a zárt szoftvereket illeti, annak elkészítésekor nagy figyelmet fordítanak a kódbiztonsági elemzésre, ami növeli a rendszer megbízhatóságát. Másrészt, mivel a fejlesztők száma gyakran kisebb, mint a nyílt forráskódú szoftverek esetében, csökken annak valószínűsége, hogy a programban meglévő sérülékenységeket találjanak. Ezenkívül az üzemeltetők és rendszerfejlesztők/gyártók, akik az ismeretlenségen keresztül a biztonságra támaszkodnak, eltitkolhatják azt a tényt, hogy a rendszerükben sérülékenységet találtak annak érdekében, hogy elkerüljék a szolgáltatásaikba vagy termékeikbe vetett bizalom csökkenését, és ezáltal elkerüljék a versenyképesség csökkenését, így hamisítványokat keltenek. termékeik biztonságába vetett bizalom. Voltak olyan esetek, legalábbis az 1960-as években, amikor egy vállalat késleltette a javítások és javítások kiadását, és vállalati szabályait előnyben részesítette az ügyfelek aggályaival vagy kockázataival szemben.
Sean O`Neil fejlesztőmérnök a meglehetősen rugalmas EnRUPT kriptográfiai algoritmus megalkotójaként ismert . A kriptoanalitikusok szűk körében olyan személyként is ismert, aki részt vett a Mifare RFID chipek titkos rejtjelének feltörésében . Ezek a chipek képezik a közlekedési kártyák, elektronikus bérletek és egyéb érintés nélküli intelligens kártyák alapját , amelyek száma ma milliárdokra tehető szerte a világon.
2010 júliusában olyan hírek jelentek meg az interneten, hogy Sean O'Neill és kollégái egy csoportja nyilvánosságra tudta hozni a jól ismert Skype IP telefonszolgáltatást védő programok forráskódját . Pontosabban, sikerült megszerezniük a Skype szolgáltatás saját titkosítási protokolljainak forráskódjait. Sean O'Neill blogjában ad egy linket a cryptolib.com oldalra , ahol elmondása szerint a kapott kódok találhatók.
Saját bevallásuk szerint Sean O'Neill és visszafejtő társai már hosszú ideje foglalkoznak a Skype biztonsági problémáival. Mivel ők a bináris kódelemzés specialistái voltak, elég gyorsan vissza tudták állítani a programot a bináris kódokból, annak ellenére, hogy a Skype programozók nagyon intenzíven alkalmaztak elfedést . Éppen azért, mert a Skype fejlesztői intenzíven használták az obfuszkálást, korábban keveseknek sikerült bináris kódokból visszaállítani a programot, akik pedig erre képesek voltak, azok nem publikálták a forráskódokat, mert félelmetesnek tűntek.
Végül Sean O'Neillnek sikerült létrehoznia egy egyenértékű kódot, amely minden főbb módban úgy működik, mint a Skype, de amelyet Skype-kód használata nélkül írnak. Bár a kód elkészítése privátban történt, néhány hét után sikerült kiszivárognia az internetre, és azonnal a Skype azonnali üzenetküldő szolgáltatásán keresztül üzeneteket küldő spammerek eszközévé vált. Sean O'Neill felelősséget érezve azért, ami történik, úgy döntött, hogy feltárja a Skype kommunikációs protokoll fő titkát - az RC4 titkosítási inicializálási vektor homályos kiterjesztési algoritmusát . Pontosabban, a cryptolib.com rendelkezik egy C programmal , amely a Skype-kliensek és a rendszer-szupercsomópontok közötti szolgáltatási forgalom visszafejtésére használható. Annak ellenére, hogy az RC4 adatfolyam-titkosítási módszert használják a szolgáltatási adatok titkosításához, nincsenek titkos kulcsok , amelyeket fel kell törni. Az egyetlen dolog, ami valóban létezik, az az állandó átalakulás, amely az olvasható információt olvashatatlanná változtatja. Ennek az algoritmusnak az volt a célja, hogy más személy ne tudjon Skype-kompatibilis alkalmazást fejleszteni, mivel a szolgáltatási adatok átvitelére szolgáló algoritmusok ismerete nélkül lehetetlen ilyen alkalmazásokat létrehozni. Ezzel védekezett a Skype kizárólagos tulajdonjogával szemben.
Bár feltörték és közzétették, ezek a műveletek semmilyen módon nem okoznak kárt, és nem fedik fel a Skype szolgáltatásban a felhasználók között küldött üzenetek és fájlok titkosságát. A hackelés csak arra a szolgáltatási csatornára irányult, amelyen keresztül a felhasználók keresési lekérdezései, profiljaik, névjegyzékeik stb. Ez az egyik legszemléletesebb példa arra, hogy még a nagyvállalatok is alkalmazzák termékeikben a „biztonság az ismeretlenségen keresztül” elvét, és ez az akció óriási anyagi károkat és a termék hitelességének csökkenését is okozhatja.
Számos példa van a Microsoft termékek homályosságán keresztüli biztonságra . Néhányat a rendszergazdák, néhányat a szoftverfejlesztők használhatnak. Mindegyikük célja a sérülékenység kockázatának csökkentése a sérülékenység elrejtésével. Néhányuknak nincs pozitív hatása, de ez nem bizonyíték arra, hogy a homályon keresztüli biztonság nem működik.
A „biztonság az ismeretlenségen keresztül” elv egyik felhasználási módja a meghajtóbetűjelek elrejtése a Windows Intézőben. Ezt az eljárást gyakran használják iskolai számítógépes laborokban, internetkávézókban vagy más olyan helyeken, ahol olyan feltételeket kell teremteni, ahol a felhasználó használhatja a számítógépet, de nem tud adatokat menteni a merevlemezre. Érdemes azonban megjegyezni, hogy a legtöbb alkalmazás továbbra is képes adatokat menteni a merevlemezre, ami nagymértékben csökkenti ennek a biztonsági intézkedésnek az értékét.
Ezenkívül a Windows gyakran alkalmaz egy módszert a megosztott adminisztrációs hálózati erőforrások (például C$, Admin$ stb.) letiltására. Az ötlet alapja, hogy ennek az eljárásnak meg kell akadályoznia, hogy a behatolók távolról csatlakozzanak egy számítógéphez. A rendszergazdai fiókkal rendelkező támadó azonban távolról is csatlakozhat adminisztrátori erőforrásokhoz. Azonban az előző eljáráshoz hasonlóan a szervezetek arról számolnak be, hogy az adminisztratív erőforrások letiltása csökkenti a rosszindulatú programok számát a hálózatokon.
A Feladatok ütemezésének engedélyezése a kiszolgálóüzemeltetőknek beállítással ütemezheti a feladatokat a Kiszolgálókezelők csoport felhasználói számára. De ne feledje, hogy a kiszolgálók üzemeltetői sokféle módon tehetik magukat rendszergazdává, így nem nagy dolog megakadályozni őket a feladatok ütemezésében. Ezt a lehetőséget azonban sok szervezet előnyben részesíti, mert lehetővé teszi, hogy a szakembereik adminisztrátorok helyett operátorok legyenek, ami csökkenti annak esélyét, hogy a szakemberek véletlenül tönkretegyék a szervert.
Egy másik példa az 500-as relatív azonosítóval ( RID ) rendelkező rendszergazdai fiók átnevezése egy ismeretlenre, amit gyakran javasolnak biztonsági szakértők, valamint néhány Microsoft-iránymutatás. Ennek a műveletnek az a jelentése, hogy a támadó nem fogja tudni a valódi rendszergazdai bejegyzés nevét. Ennek a módszernek az a hátránya, hogy az adminisztrátori fiók RID-je mindig 500, és bármely felhasználó megtudhatja a rendszergazdai fiók nevét a RID-ből.
Nézzünk egy példát az obfuszkáció használatára. Az obfuszkáció egy olyan technika, amely egy program forrás- vagy végrehajtható kódjának elhomályosítására irányul, és amelynek célja a működőképesség megőrzése, de az ilyen kódot nehéz lesz elemezni.
Az obfuszkáció alkalmazható mind az algoritmus szintjén, mind a program forráskódjának szintjén, sőt az összeállítási kód szintjén is . Például a homályos assembler kód generálása megvalósítható speciális fordítók használatával . Az ilyen fordítók hajlamosak újra kódot létrehozni a program futási környezetének dokumentálatlan szolgáltatásaival. Vannak speciális programok is a kód elhomályosítására - obfuszkátorok.
Néhány eljárás a programkód homályosítására:
1. példa ( C nyelven )
Forráskód az obfuszkálás előtt:
int COUNT = 100 ; float TAX_RATE = 0,2 ; for ( int i = 0 ; i < COUNT ; i ++ ) { adó [ i ] = eredeti ár [ i ] * TAX_RATE ; ár [ i ] = eredeti_ár [ i ] + adó [ i ]; }Az elhomályosítás után:
for ( int a = 0 ; a < 100 ; a ++ ) { b [ a ] = c [ a ] * 0,2 ; d [ a ] = c [ a ] + b [ a ];}2. példa ( Perlben )
Forráskód az obfuszkálás előtt:
az én $szűrőm ; if ( @pod ) { my ( $buffd , $buffer ) = Fájl::Temp:: tempfile ( UNLINK => 1 ); print $buffd "" ; print $buffd @pod or die "" ; print $buffd bezár $buffd vagy die "" ; @talált = $puffer ; $szűrő = 1 ; } kilépés ; sub is_szennyezett { my $arg = shift ; my $nada = substr ( $arg , 0 , 0 ); # nulla hosszúságú helyi $@ ; # a hívó verziójának megőrzése eval { eval " #" }; visszatérési hossz ($@) != 0; } sub am_taint_checking { my ( $k , $v ) = minden %ENV ; return is_szennyezett ( $v ); }Az elhomályosítás után:
sub z109276e1f2 { ( my $z4fe8df46b1 = shift ( @_ ) ) ; ( saját $zf6f94df7a7 = substr ( $z4fe8df46b1 , ( 0x1eb9 + 765 - 0x21b6 ) , ( 0 × 0849 + 1465 - 0x0e02 ) ) ) ; helyi $@ ; eval { eval ( ( "" ) ) ; } ; return ( ( hossz ( $@ ) != ( 0x26d2 + 59 - 0x270d ) ) ); } my ( $z9e5935eea4 ) ; if ( @z6a703c020a ) { ( my ( $z5a5fa8125d , $zcc158ad3e0 ) = Fájl::Temp:: tempfile ( "" , ( 0x196a + 130 - 0x19eb ) ) ) ; nyomtatás ( $z5a5fa8125d "" ) ; ( print ( $z5a5fa8125d @z6a703c020a ) vagy die ( ( ( ( "" . $zcc158ad3e0 ) . " \ x3a \ x20 " ) . $ ! ) ) ; nyomtatás ( $z5a5fa8125d "" ) ; ( bezárni ( $ z5a5fa8125d ) vagy meghalni ( ( ( ( " " ) ) ) ; ( @ z8374cc586e = $ zcc158ad3e0 ) ; ( $ z9e5935eea4 = ( 0 × 1209 + 1039 - 0 ) × 161 ; _ _ _ my ( $z0f1649f7b5 , $z9e1f91fa38 ) = mindegyik ( %ENV ) ) ; return ( z109276e1f2 ( $z9e1f91fa38 ) ) ; }Ezek az úgynevezett magas szintű elhomályosítás példái. Ha a cél a víruskód elrejtése , akkor a legtöbb esetben alacsony szintű (asszembler parancsok segítségével) elfedést, valamint automatikus obfuszkáló programokat, például Afx!AVSpoffer, EPProt és PETools használnak.
Az alapelv egy változata a kevéssé ismert programok jellemzőire épül, amelyek használata esetén a véletlenszerű és automatikus támadások során csökken a sebezhetőségek felfedezésének valószínűsége. Ennek a megközelítésnek sok neve van, és a leggyakoribb a "biztonság a kisebbségen keresztül". Léteznek még a "biztonság a ritkaság miatt", "biztonság a népszerűtlenség miatt", "biztonság az érdektelenség miatt" kifejezések is. Ez az elv túlnyomórészt annak magyarázatában található meg, hogy egy széles piaci szegmensben talált ismert sebezhetőségek száma miért magasabb, mint a program piaci részesedése által feltételezett lineáris kapcsolat , de ez a részarány tényező a program kiválasztásában néhány nagy szervezetnél. . A kisebbségi biztonság elve hasznos lehet azon szervezetek számára, amelyek nincsenek kitéve célzott támadásoknak, és hosszú távon tervezik a termék használatát. Egy piacvezető programban azonban az új sérülékenységek azonosítása nehezebb, mint a kevésbé ismert termékekben, mivel a program széleskörű elterjedtsége miatt számos sérülékenységet már azonosítottak, így egy nagy piaci részesedéssel rendelkező program alkalmasabb a szervezetek számára. állandó támadás alatt. A problémát az is bonyolítja, hogy a homályos szoftverek új sebezhetőségeinek felfedezése a szoftver minden felhasználóját támadás célpontjává teszi. A piacvezető szoftverek esetében még nagyobb annak a valószínűsége, hogy a bennük lévő új sérülékenységek véletlenül támadások célpontjává válhatnak.
Általánosságban elmondható, hogy a probléma szorosan összefügg a „biztonság a sokféleségen keresztül” elvével – a sokféle homályos program jelenléte, amelyek látszólag változatosabbak, mint a piacvezető kínálata bármilyen típusú programban, ami csökkenti a véletlenszerű programok kockázatát. támadás.
A kisebbségi biztonság elve melletti érv ellentétes a természetben megfigyelt elvvel a ragadozó-zsákmány forgatókönyvben. Ebben a forgatókönyvben az „egy ember nem harcos” elve ellentétes a „kisebbségen keresztüli biztonság” elvével. Van azonban néhány igen jelentős különbség például egy gazellára vadászó oroszlán és egy automatizált rendszer működése között. A szoftverhackelés legtöbb áldozata semmi esetre sem a támadás közvetlen célpontja.
A kisebbségi elv szerinti biztonság egyik fajtája az elavulás általi biztonság. Ez az elv például örökölt hálózati protokollok (például IPX , nem TCP / IP ) használatán alapulhat , ami csökkenti az internetről érkező támadások lehetőségét .