Testa om datorn är skyddad mot buffertöverskridningsattacker

[Gäst al6]

Alltså guuuud va coolt!

Jag vet att denna tråden i stort sett går runt i en loop men alltså jag måste bara ta upp detta. Jag gjorde ju en ganska fattig BO innan som endast var en BO men inte en riktig "exploit". Men jag blev lite inspirerad nu när tråden kom upp igen så jag bestämde mig för att fixa fram en riktig exploit. Och visst lyckades jag! Men även när jag lyckats göra en helt fungerande BO-exploit varnade Visual Studio (den studio man programmerar i) mig att programmet var fel

Alltså seriöst, Visual Studio är så jävla bra! Den varnar både innan, under, och efter man gör ett säkerhetshål. Jag ska fixa fram en lite mer tilltalande version av exploiten som man då kan använda som en fristående BO tester, eftersom jag tror den här Comodo BO Tester kan vara lite partisk

Jag bifogar en bild som visar hur Visual Studio stoppar mitt program från att köras (nästan exakt som Memory Firewall) när jag gör BO. Det finns två lägen man kan köra sina program i: Debug och Release. Debug har massa BO-tester och sånt med så det är endast när jag kör som Release som exploiten funkar, vilket är skitbra!

Stack around the variable 'buffer' was corrupted.

Detta är exakt vad som hänt; jag gjorde en variabel som jag kallar för 'buffer', och jag skrev utanför buffern så att stacken (stacken är det minne som alla buffrar och variabler ligger på) blev "korrupt".

Okej så låt mig göra exploiten lite mer tilltalande så kan man (JoWa) testa den i Memory Firewall

[JoWa]

Alltså guuuud va coolt!

Jag vet att denna tråden i stort sett går runt i en loop men alltså jag måste bara ta upp detta. Jag gjorde ju en ganska fattig BO innan som endast var en BO men inte en riktig "exploit". Men jag blev lite inspirerad nu när tråden kom upp igen så jag bestämde mig för att fixa fram en riktig exploit. Och visst lyckades jag! Men även när jag lyckats göra en helt fungerande BO-exploit varnade Visual Studio (den studio man programmerar i) mig att programmet var fel

Alltså seriöst, Visual Studio är så jävla bra! Den varnar både innan, under, och efter man gör ett säkerhetshål. Jag ska fixa fram en lite mer tilltalande version av exploiten som man då kan använda som en fristående BO tester, eftersom jag tror den här Comodo BO Tester kan vara lite partisk

Då test och testobjekt kommer från samma utvecklare är det ju inte orimligt att fatta sådana misstankar. Därför efterfrågade jag något annat program som kan bekräfta, komplettera eller motsäga det resultat som vi hittills har sett.

Jag bifogar en bild som visar hur Visual Studio stoppar mitt program från att köras (nästan exakt som Memory Firewall) när jag gör BO. Det finns två lägen man kan köra sina program i: Debug och Release. Debug har massa BO-tester och sånt med så det är endast när jag kör som Release som exploiten funkar, vilket är skitbra!

Detta är exakt vad som hänt; jag gjorde en variabel som jag kallar för 'buffer', och jag skrev utanför buffern så att stacken (stacken är det minne som alla buffrar och variabler ligger på) blev "korrupt".

Så Microsoft har uppenbarligen tekniken för att hindra buffertöverskridning. Utmärkt, och utmärkt att utvecklare så tydligt uppmärksammas på detta. Varför ser vi inte detta i Windows?

Okej så låt mig göra exploiten lite mer tilltalande så kan man (JoWa) testa den i Memory Firewall

Strålande! Sådana testprogram tycks inte finnas i mängder. Och tilltalande skall det förstås vara! Har nu CIS 3.9 alfa, så inget kan garanteras. Men andra kan testa 3.8, och jag kan testa SafeSurf.

[Gäst al6]

Skulle installera Memory Firewall för att testa själv men det fungerade inte att installera... "Rollback done" står det bara och installationsmappen blir tom så du får testa detta då.

[JoWa]

Fick detta resultat (både med och utan SafeSurf):

Memory Firewall är kanske inte W7-kompatibel. Testat Vista-läge?

[Gäst al6]

Vet inte riktigt vad SafeSurf är men jag fick igång Memory Firewall genom kompatibilitetsläget, dah!

Jag var kanske lite försiktig med att fylla buffern så att Memory Firewall inte märkte något (jag var faktiskt lite för försiktig, i praktiken lär man ju inte träffa adresserna klockrent) därför gjorde jag testet lite mer klumpigt så att den nu fyller buffern rätt ordentligt (typ 50 bytes för mycket, alltså exempel 50 tecken för mycket). Dock säger varken DEP eller Memory Firewall något fast "exploiten" lyckas helt.

Jag kör 32-bitars Windows 7 nu och det verkar ju faktiskt som att 64-bitars DEP är extremt mycket mer alert och säkert än 32-bitars DEP. DEP i 64 stängde ju programmet direkt, här i 32-bitars bara kraschar programmet efter ett tag utan att DEP ens säger något.

Memory Firewall ger visserligen små felmeddelande lite då och då så den kanske inte fungerar helt som den ska, så du kan ju testa denna uppdaterade "exploiten". Jag frågar mig ibland om jag verkligen gjort rätt, men uppenbarligen har jag det eftersom den kod som jag aldrig säger ska köras, verkligen körs efter att jag överfyllt buffern.

Kan Memory Firewall vara en bluff? För om inte denna exploiten ger något felmeddelande är ju något knasigt då jag översvämmar buffern med 50 tecken extra och returneringsadressen ändras så att annan kod körs...

[JoWa]

Samma resultat.

SafeSurf är en ”minnesbrandvägg” som medföljer CIS. Det är dock ett onödigt tillägg till CIS 3.8, men var till nytta som tillägg till CIS 3.5.

[Gäst al6]

Har du testat med Memory Firewall på?

Jag ska testa detta på x64 senare och jämföra. Alltså jag är inte 100% säker att jag gör rätt men mycket tyder på det. Jag har inte fått det att fungera i Releaseläget så jag kör i Debugläget vilket kan vara boven. Debugläget kan ju ha massa konstiga tester som fakkar upp allt. Dock tror jag inte det eftersom, som sagt, det meddelande som dyker upp endast kan visas om en riktig exploit av "säkerhetshålet" skett.

Jag ska gå till botten med det här, när jag fått det att fungera i Releaseläget och Memory Firewall fortfarande inte klagar måste Memory Firewall antingen vara fake eller helt enkelt gå efter andra kriterier än vad jag åstadkommer (typ att den endast reagerar om man gör sånna där shellcode injections vilka jag inte bemästrar ännu )

[JoWa]

Har testat det inbyggda skyddet i CIS 3.9 alfa, och även SafeSurf. Memory Firewall har jag inte installerat nu.

Du nämnde själv bristen i ditt program: shellcode injections!

[Gäst al6]

Okej så jag har nu lyckats med Releaseläget. Det var kompilatorn som optimerade bort den kod som jag inte direkt kallade på. Jag har gjort en mer tilltalande version som nu svämmar över med 100 bytes extra och då skriver över returneringsadressen som får programmet att hoppa till annan kod i programmet. Detta är ett äkta stack buffer overflow utnyttjande och enligt Comodo är det sånt här Memory Firewall ska hindra:

Comodo Memory Firewall detects the following types of attack:

Detection of Buffer Overflows which occur in the STACK memory,

Men uppenbarligen upptäcker den inte alls detta? Det här med shellcodes ska inte spela så stor roll egentligen, jag har läst på lite mer och det får väl bli en version med detta nästa gång Tycker iallafall att Memory Firewall är väldigt passivt, det här inte hindrat något jag gjort?

Testa denna nya, mitt Firewall säger inget och jag är säker på att det är rätt installerat eftersom jag fick Protected på alla tre av Comodos tester. Varningar kom upp och allt. Knasigt.

[Gäst al6]

Så ja!

Har forskat hela dagen och lyckades göra en någorlunda fungerande "stack buffer overflow shellcode exploit". Memory Firewall varnar nu och man kan då stoppa exploiten helt. Jag vill därför sammanfatta denna tråden nu:

Memory Firewall är inte fake. Den är extremt snabb och stoppar min exploit. Dock är beskrivningen av produkten helt felaktig. Memory Firewall är inte alls en "buffer-vaktare", man kan skriva över returneringsadressen och skriva flera kilobytes utanför buffern, Memory Firewall säger ändå inget. Man kan till och med ändra returneringsadressen så att helt annan kod körs utan att den bryr sig. Dock hojtar den till när man försöker köra kod som inte ligger i code-segmentet.

När man kompilerar ett program läggs all kod i code-segmentet och data i data-segmentet. All kod som finns i code-segmentet är skrivet av utvecklaren. En BO exploit lägger dock kod i en buffer, vilket lagras i data-segmentet. Därför är Memory Firewall väldigt passiv och vaktar bara en sak; att ingen kod körs från data-segmentet. Mina förra exploits har utnyttjat en BO och ändrat returneringsadressen korrekt, men jag har fortfarande kört kod från code-segmentet, därför har Memory Firewall inte brytt sig

Denna tråden och vad jag lärt mig omkring denna tråden har helt ändrat min syn på Memory Firewall, jag anser den vara ett absolut måste. Jag skulle inte bli förvånad om datorn blir helt säker med denna igång, seriöst. Det finns ju fan inga fler hot än BO som kan köras utan användarens inverkan? , en server som kör Memory Firewall borde vara totalt säker mot exakt alla utomstående hot, dock kan ju såklart servern kraschas av utomståndes indata eftersom Memory Firewall då kommer att döda serverns process som fick BO, men iallafall kommer hackarna inte vidare

Om Microsoft kunde köpa upp Memory Firewall och bygga in det i Windows, typ som DEP, hade man nog kunnat hindra en rejäl del virus och sånt mög

Det är ju så att dagens OS blir bara säkrare och säkrare, snart kan virus och liknande säga hej då Framtidens virus kommer nog bara bygge på sån här social engineering där man lurar användaren.

[Gäst al6]

Bild

[JoWa]

Applåder för ditt engagemang!

Trots den fina ikonen () får jag inte ditt program att fungera. Får upp en ruta, och klickar på Ja. Då tvärdör processen Säkerhetstest.exe. Är programmet beroende av någon tjänst som jag har inaktiverat, tro?

Fin sammanfattning av tråden! Denna teknik inbyggd i Windows (och övriga OS) vore en höjdare. Att inte alla säkerhetspaket ger detta skydd kan man också ifrågasätta. I många fall betalar ju folk för datorsäkerhet, och likväl är deras system vidöppna för denna typ av attack. Får de då vad de betalar för: datorsäkerhet?

[Gäst al6]

Nej det är nog inget fel hos dig, en annan kille med XP sa även att det inte fungerade där. Det kan ju bero på massa saker men det viktiga är att jag insåg att Memory Firewall fungerar klockrent Det var inte så lämpat att göra exploiten med mitt verktyg (Visual Studio), eftersom det hela tiden försöker motverka vad jag ska åstadkomma. Kanske kan fixa en bättre version i framtiden om jag fixar lite andra verktyg, men det är ju inte så viktigt. Tror Comodos BO Tester duger. Det är iaf kul att lära sig nya saker och jag visste inte att man kunde få så stor frihet i koden, jag menar att när man väl trängt sig genom såkerhetshålet har man rätt fria händer när det gäller att förstöra Men man ska väl fortfarande inte vara allt för paranoid, UAC är ju jättebra mot alla säkerhetshål då utnyttjanden endast har standardrättigheter i de flesta fall, som sagt. Okej men kul tråd

[Gäst al6]

Men alltså jag läser om och om igen att DEP är precis detta...

Wikipedia säger något i stil med att DEP 32-bitars är skräp medan 64-bitars DEP blandat med ASLR, vilka båda finns i Vista ska fungera riktigt bra. Dock verkar ASLR vara avstängt som standard i Vista före SP1, så jag vet inte.

Det står att DEP ska hindra kod att köras från stacken (data-segment), så DEP borde stoppa denna exploiten. Måste bara testa på x64.

[JoWa]

Nej det är nog inget fel hos dig, en annan kille med XP sa även att det inte fungerade där. Det kan ju bero på massa saker men det viktiga är att jag insåg att Memory Firewall fungerar klockrent

OK, man vet ju inte. Har hänt att annat inte har fungerat p.g.a. inaktiverade tjänster, t.ex. DCOM.

Det står att DEP ska hindra kod att köras från stacken (data-segment), så DEP borde stoppa denna exploiten. Måste bara testa på x64.

Var det inte det du gjorde i början av tråden? Du körde väl Vista x64 då?

Det finns också en jämförelse mellan CMF och DEP i ett tidigare inlägg.

[Gäst al6]

Har Windows 7 bygge 7057 x86, ska byta tillbaka till x64 och testa när jag känner för det