Säkerhet genom mörker är en princip som används för att säkerställa säkerhet inom olika områden av mänsklig verksamhet. Grundidén är att dölja insidan av ett system eller implementering för att säkerställa säkerheten.
Ett system som förlitar sig på "säkerhet genom obscurity" kan ha befintliga eller misstänkta sårbarheter , men dess ägare eller utvecklare tror att om bristerna inte är kända, kommer en angripare inte att kunna upptäcka dem. Systemet kan också använda säkerhet genom dunkel som ett av systemskyddsskikten, eftersom det ger systemutvecklare tid att fixa den upptäckta sårbarheten, medan offentliggörande av produkter och versioner gör dem till det främsta målet för att utnyttja upptäckta sårbarheter i dessa produkter och versioner. Angriparens första steg är vanligtvis informationsinsamling, en uppgift som försvåras genom att använda säkerhet genom dunkel.
Den befintliga officiella litteraturen om säkerhet genom dunkel är ganska sparsam. Säkerhetstekniska böcker hänvisar till Kerckhoffs princip från 1883, om de hänvisar till något alls.
På rättsområdet har Peter Swire skrivit om avvägningen mellan "säkerhet genom dunkel är en illusion" och militärens syn på att "rykten sänker skepp" och hur konkurrens påverkar incitamenten för avslöjande.
Principen om säkerhet genom dunkel var vanlig i kryptografiskt arbete på den tiden då i stort sett alla välinformerade kryptografer arbetade för nationella underrättelsetjänster som National Security Agency . Kryptografer arbetar nu ofta på universitet, där forskare publicerar många eller till och med alla sina resultat och offentligt testar andras design, eller i den privata sektorn, där resultaten oftare kontrolleras av patent och upphovsrätt än sekretess, så principen har förlorat en del av dess tidigare popularitet. Till exempel släpps PGP som källkod och anses allmänt (om det används på rätt sätt) vara ett kryptosystem av militär kvalitet.
Vi lägger fram argument för att använda principen. Även om det är en dålig idé att skapa ett systemförsvar som enbart förlitar sig på principen om säkerhet genom dunkel, kan det vara en smart taktik att använda denna princip för att hålla vissa detaljer om systemet hemliga i ett säkerhetssystem i lager. Till exempel, när en systemsårbarhet upptäcks av dess skapare, kan säkerhet genom dunkel vara en tillfällig barriär för angripare tills sårbarheten är åtgärdad. I det här fallet är syftet med att använda principen att på kort sikt minska risken för att utnyttja en sårbarhet i systemets huvudkomponenter.
Tänk på ett datornätverk som innehåller en känd sårbarhet. Utan att ha någon information om den specifika enheten i systemet måste en angripare bestämma sig för att använda denna sårbarhet eller inte. Om ett system är konfigurerat att upptäcka denna sårbarhet kommer det att upptäcka att det är under attack och kan svara, antingen genom att låsa systemet tills administratörer har en chans att svara, eller genom att övervaka och spåra angriparens attack, eller genom att koppla bort angriparen . Kärnan i att använda principen i denna situation är att en angripare inte snabbt kan få den nödvändiga informationen om systemet för att fatta ett bestämt beslut om förhållandet mellan risken för att bli blockerad när han försöker utnyttja en sårbarhet och eventuell belöning i fall av en framgångsrik attack. Som en konsekvens av bristen på nödvändig information om systemets struktur kan han inte heller entydigt välja den del av systemet som måste attackeras i första hand.
En annan strategi för att använda principen innebär att det finns ett dubbelt lager av sårbarheter, som båda hålls hemliga. Samtidigt låter skaparna av systemet en av sårbarheterna "läcka". Tanken är att ge angriparen en falsk känsla av säkerhet om att försvaret har övervunnits och att han har vunnit. Det kan till exempel användas som en del av ett bete (den ryska motsvarigheten till termen är "livebetsfiske").
Argument mot principen om säkerhet genom dunkel går tillbaka till Kerckhoffs princip , som fördes fram 1883 av Auguste Kerckhoffs . Denna princip säger att utformningen av ett kryptografiskt system inte ska kräva sekretess och inte ska orsaka olägenheter om det hamnar i fiendens händer. Utvecklare bör anta att hela utformningen av säkerhetssystemet är känd för angriparna, med undantag för kryptonycklarna (säkerheten för ett kryptografiskt system ligger helt och hållet i den kryptografiska nyckeln). 1940 formulerade Claude Shannon denna princip som "fienden känner till systemet."
Ju fler punkter för möjliga kompromisser som finns i systemet, desto mer sannolikt är det att en attackstrategi på en av dessa punkter finns eller kommer att utvecklas. System som innehåller struktur- eller verksamhetssekretess som också är punkter för möjliga kompromisser är mindre säkra än liknande system utan dessa punkter om den ansträngning som krävs för att erhålla en sårbarhet till följd av att en projektstruktur eller arbetsmetod avslöjas, samt ansträngningen att utnyttja denna sårbarhet, mindre ansträngning krävs för att få den hemliga nyckeln. Systemsäkerhetsnivån reduceras till den ansträngning som krävs för att utnyttja denna sårbarhet.
Till exempel, om någon har en reservnyckel under mattan, om dörrarna är låsta från utsidan, förlitar han sig på säkerhet genom dunkel. Den teoretiska säkerhetssårbarheten är att någon skulle kunna bryta sig in i huset genom att öppna dörren med denna reservnyckel. Dessutom, eftersom inbrottstjuvar ofta känner till de avsedda gömställena, löper ägaren av bostaden större risk för inbrott genom att dölja nyckeln, eftersom ansträngningen som krävs för att hitta nyckeln sannolikt är mindre än ansträngningen som krävs för att bryta sig in (t.ex. genom att bryta in) på annat sätt, till exempel genom glas. Ägaren lade till en sårbarhet - det faktum att inmatningsnyckeln är lagrad under mattan - i systemet, och en sårbarhet som är mycket lätt att gissa och utnyttja.
Tidigare har flera mjukvarualgoritmer eller system med döljande interna detaljer sett dessa interna detaljer blivit offentliga. Oavsiktligt avslöjande har inträffat vid flera tillfällen, till exempel i det berömda GSM- fallet överfördes konfidentiell dokumentation angående ett chiffer till University of Bradford utan att de vanliga sekretesskraven ställdes [1] . Dessutom upptäcktes och utnyttjades sårbarheter i programvara även när de interna detaljerna förblev hemliga. Sammantaget visar dessa och andra exempel att det är svårt eller ineffektivt att hålla detaljerna i system och algoritmer hemliga.
Säkerhet genom dunkel erkänns inte som ett lämpligt tekniskt tillvägagångssätt för systemsäkerhet, eftersom det strider mot "KISS"-principen . National Institute of Standards and Technology rekommenderar specifikt att du använder säkerhet genom dunkel i högst ett dokument. Enligt NIST bör "ett säkerhetssystem inte vara beroende av sekretessen för en implementering eller dess komponenter" [2] .
Det råder en allmän enighet, även bland dem som förespråkar säkerhet genom dunkel, att principen om "säkerhet genom dunkel" aldrig ska användas som en primär säkerhetsåtgärd. Detta är i bästa fall en sekundär åtgärd, och avslöjande av tvetydighet bör inte leda till kompromisser .
Värdet av att använda principen när man skapar öppen eller stängd programvara är mycket olika och tvetydig. Överväg processen att skapa programvara med öppen källkod. Oftast är utvecklare mer intresserade av att skapa ny kod än att analysera befintlig kod för sårbarheter. Eftersom skapandet av programvara med öppen källkod är en frivillig insats, läggs generellt mindre vikt på säkerhet än om en av författarnas uppgifter skulle vara att analysera säkerheten i programmet. Å andra sidan finns Linus lag , som säger att "med tillräckligt många ögon flyter buggar upp till ytan", antyder ökad säkerhet för algoritmer och protokoll, vars beskrivning publiceras. Fler människor kan se detaljerna i sådana algoritmer, identifiera brister och åtgärda dem tidigare. Anhängare av denna uppfattning tror att frekvensen och svårighetsgraden av konsekvenserna av en kompromiss kommer att vara mindre än för proprietär eller hemlig programvara. Av allt detta kan vi dra slutsatsen att när det gäller att skapa programvara med öppen källkod beror säkerheten direkt på programmets popularitet, det vill säga ju högre popularitet, desto fler frivilliga analyserar programkoden och desto högre är sannolikheten för att hitta sårbarheter i det. Till stöd för detta kommer vi att ge ett exempel på att Linux -källkoden har 0,17 fel per tusen rader källkod [3] , medan sluten kommersiell programvara har i genomsnitt 20-30 fel per 1000 rader källkod.
När det gäller sluten programvara, när man skapar den, ägnas mycket uppmärksamhet åt kodsäkerhetsanalys, vilket ökar systemets tillförlitlighet. Å andra sidan, eftersom antalet utvecklare ofta är mindre än i fallet med programvara med öppen källkod, minskar sannolikheten för att hitta befintliga sårbarheter i programmet. Dessutom kan operatörer och systemutvecklare/tillverkare som förlitar sig på säkerhet genom dunkel hemlighålla det faktum att en sårbarhet har hittats i deras system för att undvika att minska förtroendet för deras tjänster eller produkter och därför undvika att minska dess konkurrenskraft och på så sätt skapa falska förtroende för sina produkters säkerhet. Det har förekommit fall, åtminstone så långt tillbaka som på 1960-talet, där ett företag försenat utgivningen av korrigeringar och patchar och prioriterat sina företagsregler framför kundernas problem eller risker.
Utvecklingsingenjören Sean O`Neil är känd som skaparen av den ganska flexibla EnRUPT- krypteringsalgoritmen . Han är också känd i snäva kretsar av kryptoanalytiker som en person som deltog i att bryta det hemliga chifferet i Mifare RFID - chips . Dessa marker utgör grunden för transportkort, elektroniska pass och andra kontaktlösa smarta kort , som idag uppgår till miljarder runt om i världen.
I juli 2010 dök det upp nyheter på Internet om att Sean O'Neill och en grupp kollegor kunde avslöja källkoderna för program som skyddar den välkända Skype IP-telefonitjänsten . Mer specifikt lyckades de få tag i källkoderna för proprietära krypteringsprotokoll för Skype-tjänsten. I sin blogg ger Sean O'Neill en länk till sajten cryptolib.com , där enligt honom de mottagna koderna finns.
Av egen räkning har Sean O'Neill och hans andra reverse engineer faktiskt hanterat Skypes säkerhetsproblem under en lång tid. Eftersom de var specialister på binär kodanalys kunde de återställa programmet från binära koder ganska snabbt, trots att Skype-programmerarna använde mycket intensiv obfuskering . Just för att utvecklarna av Skype använde obfuskering intensivt var det få som lyckades återställa programmet från binära koder tidigare, och de som kunde göra detta publicerade inte källkoderna, eftersom de såg skrämmande ut.
Till slut lyckades Sean O'Neill skapa en likvärdig kod som fungerar som Skype i alla större lägen, men som är skriven utan att använda Skype-koden. Även om skapandet av koden gjordes privat, lyckades den efter några veckor läcka ut på Internet, och den blev omedelbart ett verktyg för spammare som skickade meddelanden via Skypes snabbmeddelandetjänst. Sean O'Neill kände sig ansvarig för vad som händer och bestämde sig för att lägga ut huvudhemligheten för Skypes kommunikationsprotokoll - en förvirrad förlängningsalgoritm för RC4 -chifferinitieringsvektorn . Mer specifikt har cryptolib.com ett C - program som kan användas för att dekryptera tjänsttrafik mellan Skype-klienter och systemsupernoder. Trots att RC4-strömkrypteringsmetoden används för att kryptera tjänstens data, finns det inga hemliga nycklar som behöver knäckas. Det enda som verkligen existerar är en ständig omvandling som gör läsbar information till oläsbar. Innebörden av denna algoritm var att inga andra personer kunde utveckla applikationer som är kompatibla med Skype, för utan att känna till algoritmerna för överföring av tjänstdata är det omöjligt att skapa sådana applikationer. Det var ett försvar för Skypes exklusiva ägande av sitt system.
Även om de är hackade och publicerade, skadar dessa åtgärder inte på något sätt och avslöjar inte konfidentialiteten för meddelanden och filer som skickas i Skype-tjänsten mellan användare. Hacking riktades endast till tjänstekanalen, genom vilken användarsökfrågor, deras profiler, kontaktlistor och så vidare överförs. Detta är ett av de tydligaste exemplen på hur även stora företag använder principen om ”säkerhet genom dunkel” i sina produkter, och att denna åtgärd kan orsaka både enorm ekonomisk skada och minskad produkttrovärdighet.
Det finns många exempel på säkerhet genom otydlighet i Microsoft- produkter . Vissa av dem kan användas av systemadministratörer, andra av mjukvaruutvecklare. Alla syftar till att minska risken för sårbarhet genom att dölja denna sårbarhet. En del av dem kanske inte har en positiv effekt, men detta är inte ett bevis på att säkerhet genom dunkel inte fungerar.
En användning av principen "säkerhet genom obscurity" är möjligheten att dölja enhetsbokstäver i Utforskaren i Windows. Denna procedur används ofta i skolans datorsalar, internetkaféer eller andra platser där det är nödvändigt att skapa förutsättningar där användaren kan använda datorn, men inte kan spara data på hårddisken. Det är dock värt att notera att de flesta applikationer fortfarande kan spara data på hårddisken, vilket kraftigt minskar värdet av denna säkerhetsåtgärd.
Dessutom implementerar Windows ofta en metod för att inaktivera delade administrativa nätverksresurser (som C$, Admin$, etc.). Grunden för tanken är att denna procedur ska förhindra inkräktare från att fjärransluta till en dator. En angripare med ett administratörskonto kan dock fjärransluta till administrativa resurser. Men precis som med den tidigare proceduren rapporterar organisationer att inaktivering av administrativa resurser minskar mängden skadlig programvara i nätverk.
Alternativet Tillåt serveroperatörer att schemalägga jobb låter dig schemalägga jobb för användare i gruppen Serveroperatörer. Men kom ihåg att serveroperatörer kan göra sig själva till administratörer på många olika sätt, så att hindra dem från att schemalägga jobb är ingen stor sak. Det här alternativet föredras dock av många organisationer eftersom det tillåter deras specialister att vara operatörer istället för administratörer, vilket minskar risken för att specialister av misstag förstör servern.
Ett annat exempel är att byta namn på administratörskontot med en relativ identifierare ( RID ) på 500 till något okänt, vilket ofta rekommenderas av säkerhetsexperter, samt vissa Microsoft-riktlinjer. Innebörden av denna operation är att angriparen inte kommer att känna till namnet på den riktiga administratörsposten. Nackdelen med denna metod är att administratörskontot alltid har ett RID på 500, och alla användare kan ta reda på namnet på administratörskontot från RID.
Låt oss ge ett exempel på hur du använder obfuskation. Obfuskering är en teknik som syftar till att fördunkla källkoden eller den körbara koden för ett program, vars syfte är att bevara funktionsduglighet, men sådan kod kommer att vara svår att analysera.
Obfuskation kan tillämpas både på algoritmnivå och på nivån för programmets källkod, och till och med på nivån för assemblerkod . Till exempel kan genereringen av obfuskerad assemblerkod uppnås genom användning av speciella kompilatorer . Sådana kompilatorer tenderar att återskapa kod med hjälp av odokumenterade funktioner i programmets runtime-miljö. Det finns också speciella program utformade för att fördunkla koden - obfuscators.
Några procedurer för att obfuskera programkod:
Exempel #1 (på C- språk )
Källkod före förvirring:
int COUNT = 100 ; float TAX_RATE = 0,2 ; för ( int i = 0 ; i < ANTAL ; i ++ ) { moms [ i ] = ursprungspris [ i ] * TAX_RATE ; pris [ i ] = ursprungspris [ i ] + moms [ i ]; }Efter förvirring:
för ( int a = 0 ; a < 100 ; a ++ ){ b [ a ] = c [ a ] * 0,2 ; d [ a ] = c [ a ] + b [ a ];}Exempel #2 (I Perl )
Källkod före förvirring:
mitt $filter ; if ( @pod ) { my ( $buffd , $buffer ) = Fil::Temp:: tempfil ( UNLINK => 1 ); skriv ut $buffd "" ; print $buffd @pod or die "" ; print $buffd stäng $buffd eller dö "" ; @hittad = $buffert ; $filter = 1 ; } avsluta ; sub is_tainted { my $arg = shift ; min $nada = substr ( $arg , 0 , 0 ); # noll-längd lokal $@ ; # bevara uppringarens version eval { eval " #" }; returlängd ($@) != 0; } sub am_taint_checking { my ( $k , $v ) = varje %ENV ; return is_tainted ( $v ); }Efter förvirring:
sub z109276e1f2 { ( my $z4fe8df46b1 = shift ( @_ ) ) ; ( min $zf6f94df7a7 = substr ( $z4fe8df46b1 , ( 0x1eb9 + 765 - 0x21b6 ) , ( 0 × 0849 + 1465 - 0x0e02 ) ) ) ; lokala $@ ; eval { eval ( ( " " ) ) ; } ; return ( ( längd ( $@ ) != ( 0x26d2 + 59 - 0x270d ) ) ); } min ( $z9e5935eea4 ) ; if ( @z6a703c020a ) { ( my ( $z5a5fa8125d , $zcc158ad3e0 ) = File::Temp:: tempfile ( "" , ( 0x196a + 130 - 0x19eb ) ) ) ; print ( $z5a5fa8125d "" ) ; ( skriv ut ( $z5a5fa8125d @ z6a703c020a ) eller dö ( ( ( ( " " . $zcc158ad3e0 ) . " \ x3a \ x20 " . $! ) ) ; print ( $z5a5fa8125d "" ) ; ( nära ( $z5a5fa8125d ) eller dö ( ( ( ( " " ) ) ) ) ; ( @z8374cc586e = $zcc158ad3e0 ) ; ( $z9e5935eea4 = ( 0 × 1209 + 1039 - 0 } × 1039 - 0 } ex 161 7 sub z 161 ; 1617 sub z 2 ; my ( $z0f1649f7b5 , $z9e1f91fa38 ) = varje ( %ENV ) ) ; retur ( z109276e1f2 ( $z9e1f91fa38 ) ) ; }Detta är exempel på så kallad högnivåobfuskation. Om målet är att dölja viruskoden används i de flesta fall lågnivåobfuskering (med hjälp av assemblerkommandon) samt automatiska obfuskationsprogram som Afx!AVSpoffer, EPProt och PETools.
En variant av grundprincipen är baserad på egenskaperna hos föga kända program, som när de används minskar sannolikheten för att upptäcka sårbarheter i slumpmässiga och automatiska attacker. Detta tillvägagångssätt har många namn, där "säkerhet genom minoritet" är det vanligaste. Det finns också begreppen "trygghet genom sällsynthet", "trygghet genom impopularitet", "trygghet genom ointresse". Denna princip återfinns främst för att förklara varför antalet kända sårbarheter som hittas i ett program för ett brett marknadssegment tenderar att vara högre än det linjära förhållandet som impliceras av programmets marknadsandel, men denna andel är en faktor i programvalet för vissa stora organisationer . Principen om säkerhet av en minoritet kan vara användbar för organisationer som inte utsätts för riktade attacker och planerar att använda produkten på lång sikt. Att identifiera nya sårbarheter i ett marknadsledande program är dock svårare än i mindre kända produkter, eftersom många sårbarheter redan har identifierats på grund av programmets breda spridning, så ett program med stor marknadsandel är mer lämpligt för organisationer under konstant attack. Problemet kompliceras också av det faktum att upptäckten av nya sårbarheter i obskyr programvara gör alla användare av den programvaran till ett mål för attack. För marknadsledande programvara är sannolikheten att nya sårbarheter i dem oavsiktligt kan bli ett mål för attacker ännu högre.
I allmänhet är problemet nära relaterat till principen som kallas "säkerhet genom mångfald" - förekomsten av ett brett utbud av obskyra program, uppenbarligen mer olika än marknadsledarens erbjudande i någon typ av program, vilket minskar riskerna för en oavsiktlig ge sig på.
Argumentet för principen om säkerhet med hjälp av en minoritet strider mot principen i naturen i scenariet rovdjur-byte. I detta scenario motverkar principen "en man är inte en krigare" principen om "säkerhet genom en minoritet". Det finns dock några mycket betydande skillnader mellan till exempel ett lejon som jagar en gasell och driften av ett automatiserat system. De flesta offer för mjukvaruhackning är inte på något sätt ett direkt mål för attack.
En typ av minoritetssäkerhet är säkerhet genom inkurans. Denna princip kan till exempel vara baserad på användningen av äldre nätverksprotokoll (som IPX , inte TCP / IP ), vilket minskar möjligheten för attacker från Internet .