Är det bara jag som tycker att XP:s (sp2) nya brandvägg är fantastiskt bra?

tydal skrev:

Ja, men brandväggen ska ju hindra trojanen från att agera server. Det är ju det man har brandväggar till. Man stänger alla inkommande portar just för att det inte ska spela någon roll om någon server drar igång, för den ska ändå inte få access.

Nej nej nej, brandväggen i XP har aldrig skyddat från trafik som initieras inifrån! Hur många gånger ska detta behöva sägas :)

tydal skrev:

Har man konfigurerat sin dator rätt så man inte har någon server igång då behöver man ju ingen brandvägg. Då är ju alla portar stängda. Men man har ju ändå brandvägg just för att ifall det skulle dyka upp något okänt program så ska det inte kunna dra igång en fungerande server.

Se ovan, du blandar ihop olika saker här och blandar in önskad funktionalitet med verkligheten.

tydal skrev:

Nja, det den gör är att den kallar sig för ett program som Windows litar på och därmed bryr sig inte brandväggen om den utan den får öppna portar som den vill.

Om detta stämmer, hur kommer då piggybacking in i sammanhanget? Då initeras det ju som vilken applikation som helst från insidan så det spelar ju ingen roll vad den egentligen kallas sig. Återigen, XP's brandvägg stoppar inte utgående trafik!

tydal skrev:

Att stänga ner brandväggar och antivirusprogram är en sak. Det är ju svårt att komma ifrån. Men att programmet är felkonstruerat så det släpper igenom icke godkända program och säger att allt är okej, det är en annan. Det innebär att man inte kan lita på att programmet fungerar trots att det är igång.

Återigen helt irrelevant. Detta är funktionalitet inte finns och aldrig har funnits i brandväggen. Ska jag säga meningen igen? Nnjae, jag refererar till de två jag redan nämnt ovan ;)

Jag säger däremot en annan sak igen. Har du fått in en trojan genom att DU exekverat skadlig kod på din maskin så har du helt andra problem att oroa dig för än att brandväggen släpper igenom trafik inifrån och ut. Din maskin är ägd helt enkelt...

legis, jag förstår inte varför du börjar prata om trafik som initieras inifrån. Länken och sårbarheten i brandväggen handlar om trafik som initieras utifrån. Inkommande trafik. Just sådan som brandväggen ska skydda mot. Det syns tydligt i källkoden och i beskrivningen.

Så här funkar TCP:
* Någon försöker CONNECT:a till en IP-adress och en port. Det CONNECT-kommandot gör är att skicka SYN.
* Om det finns en dator i andra änden men den inte har någon server igång på den aktuella porten svarar den med RST (connection refused).
* Om datorn i andra änden har en server igång på den aktuella porten (dvs den har ett program som kör LISTEN på den porten) så svarar den med ACK och skickar sedan SYN.
* Om den som initierade kontakten nu svarar med ACK så är förbindelsen upprättad och de två datorprogrammen kan snacka med varandra över Internet.

Men om vi nu installerar en brandvägg på datorn med serverprogrammet så kommer det att bli skillnad. Det som händer då är att brandväggen inte släpper fram SYN och den som försöker ansluta kommer aldrig att få något svar.

Så om vi inte vill att någon ska kunna ansluta till vår server kan vi använda en brandvägg. Eller så kan vi ju förstås avsluta serverprogrammet. Eller konfigurera det rätt så det bara accepterar anslutningar från localhost (eller vad vi nu vill).

En brandvägg är bra att ha om man inte har koll på vilka serverprogram som körs (exempelvis tjänster som ingår i Windows) eller som skydd mot att serverprogram startas oavsiktligt (exempelvis trojaner).

Tyvärr har ju brandväggen i XP visat att den i nuläget inte klarar av de uppgifterna och det enda den är bra för (vilket naturligtvis inte är fy skam) är nybörjare som inte kan konfigurera sin dator.

Kalla mig dum eller någon liknande synonym men jag ser inte att detta initieras utifrån ur brandvägssynpunkt (hoppas du förstår vad jag menar). Det jag ser är något som kräver att det redan finns ett program körandes på insidan, i detta fallet en trojan som lyssnar på en viss port. Har du lyckats få någon att installera en tjänst på din maskin som lyssnar på en viss port så kan den tjänsten givetvis göra vadsomhelst. Eller som ngn sade på bugtraq:

To further demonstrate my point, I wrote this exploit that will disable the WinXP firewall as well, simply extract this text into a .bat file and double-click on it:

net stop "Windows Firewall/Internet Connection Sharing (ICS)"

Din maskin är ägd redan där.

Brandväggen i XP har stateful packet inspection, så detta kommer inte att fungera på annat sätt än att du redan har skadlig kod på din maskin.

legis skrev:

Kalla mig dum eller någon liknande synonym men jag ser inte att detta initieras utifrån ur brandvägssynpunkt (hoppas du förstår vad jag menar).

Jag kallar dig inte dum bara för att du inte kan samma saker som jag. Jag vet bara inte hur mycket du vet, så jag har lite svårt att hitta rätt nivå. Det är ganska lätt när man pratar med någon IRL, för då ser man på ansiktsuttryck och kan liksom hålla en tvåvägskommunikation. Man märker (oftast) direkt när någon inte förstår och man kan snabbt anpassa sig. (Jag jobbar som lärare.) Men så här som vi gör nu, att i princip skriva brev fram och tillbaka, då är det svårt att hitta rätt.

legis skrev:

Det jag ser är något som kräver att det redan finns ett program körandes på insidan, i detta fallet en trojan som lyssnar på en viss port.

Ja, det är förutsättningen för att man överhuvudtaget ska kunna göra intrång i en dator. Finns det inget program som svarar så går det inte att göra något. En brandväggs uppgift är att se till att det inte blir något svar.

Kanske det klarnar om jag ber dig beskriva hur du upplever att en brandvägg fungerar? Varför har du en brandvägg? Vad skyddar den dig mot? Hur skyddar den?

legis skrev:

net stop "Windows Firewall/Internet Connection Sharing (ICS)"

Jag har dålig koll på Windows' behörighetssystem, men kan verkligen vanliga användare avsluta en så viktig process?

Poängen med det här säkerhetshålet är ju att du inte behöver avsluta brandväggen eftersom den har inbyggda brister du kan använda.

legis skrev:

Din maskin är ägd redan där.

Den som kan exekvera kod som Administratör äger systemet, ja.

Nja, du missar helt min poäng. För att få första biten ur världen, jag har bra koll på hur både TCP och brandväggar fungerar efter att ha arbetat med detta på ganska komplicerad nivå under mer än 5 år.

Min poäng är att detta inte är specifikt för XP's brandvägg och i sig inte direkt kan sägas vara ett problem på det sätt artikeln vill få det till. Givetvis beror allt på var man drar gränsen, men om du har installerat en trojan på din maskin så är det en klen ursäkt att sedan skylla på brandväggen. Det är ju som att ha rootkits på sin maskin som lyssnar på port 80 eller 443. Finns det på din maskin så är skadan redan skedd. Du borde se över ditt system och fråga dig hur du fick trojanen installerad istället. Kollar man på den sida som finns refererad ovan så måste du köra igång denna tjänst manuellt. D.v.s. användaren måste starta ett "program" på sin maskin.

Detta "pogram" "öppnar" sedan upp en port utåt och givetvis är den då åtkomlig utifrån. Trojanen kan i sig ha vilka funktioner somhelst. Vill du stoppa detta så skaffa en hårdvarubrandvägg istället och styr portarna där. Detta är ju en självklarhet som inte har det minsta med diskussionen att göra :)

Mitt exempel ovan var menat att om jag kan få dig att exekvera ett program hursomhelst på din maskin, så är det ganska illa. Dessutom är risken ganska stor att om du har en egen maskin så är du dessutom inloggad som lokal admin, vilket bara gör saken ännu värre och öppnar för ytterligare risker som att tjänster kan stoppas, användare kan läggas till etc.

Jag var nog för vag i mina insinuationer ovan så för att klargöra det ytterligare, du har fel :)

legis skrev:

Detta "pogram" "öppnar" sedan upp en port utåt och givetvis är den då åtkomlig utifrån. Trojanen kan i sig ha vilka funktioner somhelst.

Ja? Det är ju precis sådana scenarion man har en mjukvarubrandvägg till, att förhindra trafik initierad utifrån mot servertjänster på datorn.

Om nu en mjukvarubrandvägg INTE kan förväntas skydda datorn mot trafik till serverprocesser som lyssnar på portar som man inte aktivt öppnat, vad är då vitsen överhuvudtaget?

Du har upprepat mantrat "brandväggen skyddar inte mot trafik som initieras inifrån" och det stämmer ju, men i detta fall så handlar det ju inte om det! Att det finns en lyssnarprocess på datorn betyder inte att trafiken initieras inifrån, det ligger ju i ordets betydelse, LYSSNAR. Det är ju utifrån trafiken initieras, genom att någon ropar till LYSSNAREN: "tjenare, nu penetrerar jag brandväggen!" och LYSSNAREN svarar "gör det för tusan, det är öppet, välkommen!".

Inkommande trafik skall enbart tillåtas om det finns en brandväggsregel som tillåter inkommande trafik på den porten. I det här fallet så ser det ju ut som ett klart säkerhetshål, inga serverprocesser ska ju själva få öppna upp ett hål genom brandväggen utan att användaren är medveten om det, i så fall är något trasigt.

The guard working in the firewall gate says: IT'S A CHICKEN! OPEN THE GATES AND PARK IT NEXT TO THE BIG WOODEN HORSE!

hi hi...

sgtpepper skrev:

Inkommande trafik skall enbart tillåtas om det finns en brandväggsregel som tillåter inkommande trafik på den porten. I det här fallet så ser det ju ut som ett klart säkerhetshål, inga serverprocesser ska ju själva få öppna upp ett hål genom brandväggen utan att användaren är medveten om det, i så fall är något trasigt.

Om inte jag läst helt fel så bygger denna trojan på sessmgr. Den startar upp sessmgr i användarens context och sedan trycker den in kod i minnet för sessmgr. Detta är debugteknik och det den i praktiken gör är att skriva om hur sessmgr ska fungera. Själva koden är då skriven till att lyssna på port 333. MEN det är här brandväggen kommer in. sessmgr är tillåten i brandväggen by default, om till exempel remote assistance är påslaget. Detta står att läsa i MSDN för de som vill kolla på det.

Nu kan detta vara fel forum att posta detta på för folk drar alla möjliga konstiga slutsatser om saker de inte kan något om, men rent kortfattat så finns det faktiskt en regel i brandväggen som tillåter sessmgr och därför "fungerar" trojanen. Det är ingen magi....

Det är hur lätt som helst att testa att brandväggen fungerar som det är tänkt genom att till exempel installera IIS. IIS lyssnar by default på port 80, men inga anslutningar utifrån kommer att tas emot förrän ni gjort en exception i brandväggen.

Om inte jag läst helt fel så bygger denna trojan på sessmgr. Den startar upp sessmgr i användarens context och sedan trycker den in kod i minnet för sessmgr. Detta är debugteknik och det den i praktiken gör är att skriva om hur sessmgr ska fungera. Själva koden är då skriven till att lyssna på port 333. MEN det är här brandväggen kommer in. sessmgr är tillåten i brandväggen by default, om till exempel remote assistance är påslaget. Detta står att läsa i MSDN för de som vill kolla på det.

Men faktum kvarstår ju. En binär, som körs utan adminrättigheter kan lägga sig och lyssna på en port, och anslutningar initierade utifrån till den binären går rakt igenom "brandväggen". Utan att användaren aktivt tillåtit denna trafik. Är inte speciellt säkert i mina ögon (sedan anser jag i.o.f.s. inte att det bara beror på "brandväggen" i XP, utan även operativsystemet i sig).

Visst kan en trojan stänga av vilken brandvägg som helst, om trojanen installeras med administratörsrättigheter. Men så var ju inte fallet här.

Visst är det simpla paketfiltret i SP2 bättre än ingenting, men det fins ju bra mycket bättre produkter att ladda ner gratis.

Nu kan detta vara fel forum att posta detta på för folk drar alla möjliga konstiga slutsatser om saker de inte kan något om ...

Nu skall du kanske inte utgå ifrån att det är du som har monopol på kunskaperna här. Finns nog en hel del kunnigt folk här misstänker jag, både amatörer och proffs.

... men rent kortfattat så finns det faktiskt en regel i brandväggen som tillåter sessmgr och därför "fungerar" trojanen.

Min brandvägg hade upptäckt att det inte handlar om samma lyssnande applikation längre, och hade inte tillåtit trafiken.

Orkar inte dra igenom hela saken igen. Läs ovan, jag säger samma sak igen. Det finns en regel tillåten i brandväggen och det finns inget som säger att du måste vara admin för att skapa något som körs i din user context.

Resten kommenterar jag inte alls eftersom det borde vara uppenbart vad jag menar.

Edit:
Om du nu bryr dig så väldigt mycket om vad användare kan och inte kan göra så ta en titt på de 200 nya policies som finns för SP2, software restriction policies och ipsec.

Läs ovan, jag säger samma sak igen. Det finns en regel tillåten i brandväggen och det finns inget som säger att du måste vara admin för att skapa något som körs i din user context.

Att man kan byta ut den binär som lyssnar på porten utan att brandväggen reagerar är en brist, jämfört med konkurrerande brandväggar. Så är det bara.

Brandväggen i SP2 är som sagt bättre än den som fanns i XP tidigare, men den har en bra bit upp till sina konkurrenter (och då inkluderar jag gratisbrandväggarna).

det där har ingenting med brandväggen i sig att göra. det fungerar med vilken brandvägg som helst. testa själv.

brandväggen i XP har dessutom stateful packet inspection så den är i vissa avseenden klart bättre än andra brandväggar. Problemet som diskuteras här är inget brandväggsproblem.

Det lär inte fungera med min (Kerio Personal Firewall), eftersom den kollar MD5-signaturen på binären innan trafiken tillåts. Har binären bytts ut så får användaren upp en fråga om trafiken skall tillåtas eller inte.

Robban skrev:

Det lär inte fungera med min (Kerio Personal Firewall), eftersom den kollar MD5-signaturen på binären innan trafiken tillåts. Har binären bytts ut så får användaren upp en fråga om trafiken skall tillåtas eller inte.

Det är absolut inte helt omöjligt att det fungerar ändå. Zone Alarm kollar också MD5-signatur men trillar dit. Du borde testa.

Vilken binär kollar Kerio? Den som har laddats in i minnet eller den på disken? Och när kollar den?

Finessen med den här luckan är alltså att den modifierar det godkända programmet runtime. Den startar ett tillåtet program och använder sedan WriteProcessMemory för att stoppa in sin kod.

Finessen med den här luckan är alltså att den modifierar det godkända programmet runtime. Den startar ett tillåtet program och använder sedan WriteProcessMemory för att stoppa in sin kod.

Du menar alltså att Windows tillåter att en vanlig användarprocess går in och skriver över minnet till en process som körs som en annan användare? Eller körs serverprocessen som den användare som är inloggad (det är ju lika illa det)?

Då ber jag legis om ursäkt. Han har rätt i att just detta problem inte är ett brandväggsproblem (ändrar dock inte det faktum att XP:s brandvägg har en bit kvar till konkurrenterna). :)

Nä, det klarar nog inte Kerio heller (skulle tro att den kollar mot disk) om jag hade haft den porten öppen. Ingen brandvägg är ju säkrare än operativsystemet den körs på.

Det är här som NX-skyddet kommer in. Om jag dessutom inte har helt fel så är detta under vissa omständigheter, precis som i Windows fall, möjligt även i andra OS-produkter.

Är det någon som vet om det finns en patch via windows update ännu?

Patch för vad? Inget är sönder..