Serie Zero Day – Teil 4

Die Einschätzung von patchlosen Verletzlichkeiten und der resultierenden Situation ist nicht ganz einfach. Entsprechend weit gehen zuweilen die Meinungen auseinander. Wie könnte eine solide Basis für die Beurteilung dieser Problematik aussehen?

Ein möglicherweise solider Ausgangspunkt könnte Risikomanagment sein. Eine Zero Day Situation wird als vorübergehendes zusätzliches Risikopotential für die betriebliche IT betrachtet.

Aus dieser Perspektive lässt sich nun die Problemstellung besser fassen: Stellt eine laufende Zero Day Situation eine relevante Erhöhung des Risikos für die nächsten Tage / Wochen dar? Ist das Ausmass der Risikoerhöhung so gross, dass Qualitätsziele in Frage gestellt werden und Workaround Massnahmen in Frage kommen? Steht die Risikominderung in einem angemessenen Verhältnis zu Aufwand und möglichen Funktionsbeschränkungen?

Nach der Erhöhung des Risikos zu fragen, wirft zwei Problemkreise auf. Einmal ist die Frage bezogen auf des das ‚normale‘ alltägliche Risiko. Dazu sind die Vorstellungen oft verschwommen. Eine Einschätzung des Basisrisikos vorzunehmen, ist aber unumgänglich, wenn die relative Risikoerhöhung durch eine Zero Day Situation bewertet werden soll. Niemand würde irgendwelche Aktionen auf zwanzig Doktoranden-PCs verstehen, wenn eine Zero Day Situation das Risiko für zwei Wochen um drei Prozent erhöht. Hingegen dürfte das Management beispielsweise einer Finanzabteilung durchaus Massnahmen befürworten, wenn das Risiko auf Wochen hinaus um mehrere hundert Prozent höher erscheint.

Gesichtspunkte

Die zweite Herausforderung besteht darin, das zusätzliche Risikovolumen abzuschätzen, das auf eine bis zwei Wochen durch eine ungepatchte Verletzlichkeit entsteht. Wichtig ist dabei, eine Einschätzung immer auf ein konkretes Umfeld zu beziehen. Es sind verschieden paar Schuhe, Aussagen über die ganze Welt, eine Hochschule oder ein bestimmtes Institut zu machen. Das Risikopotential muss über eine kombinierte Analyse verschiedener Elemente abgeschätzt werden:

1. Die technische Abschätzung der Verletzlichkeit klärt, ob zentrale Mechanismen betroffen sind, Malware entwickelt und verbreitet werden kann, gewisse Mechanismen sich dämpfend auf die Ausnützbarkeit der Verletzlichkeit auswirken kann.
2. Existiert ein Exploit? Ein Exploit für sich klärt gewisse Aspekte der Ausnützbarkeit.
3. Existiert sich verbreitende Malware? Das klärt weitere Aspekte der Ausnützbarkeit und generiert zumindest ein leicht erhöhtes Risiko.
4. Verbreitungsdynamik. Gibt es eine relevante Dynamik der Verbreitung und welche Milieus sind betroffen?
5. Kontaktwahrscheinlichkeit. Lassen die Verbreitungsmechanismen eine relevante Wahrscheinlichkeit erwarten, dass eigenen Maschinen mit der Malware in Kontakt kommen?
6. Resilienz. Sind die betrachteten Maschinen durch ihre Ausstattung, Softwareversion und Konfiguration in einem relevaten Ausmass anfällig dafür, bei einem Kontakt auch kompromittiert zu werden.
7. Dauer. Wann ist ein regulärer Patch zu erwarten, welcher der Zero Day Situation ein Ende setzt?

Zeitschwellen

Mit diesen Fragestellungen müssen betroffene Akteure an zwei Zeitschwellen aktiv werden.
Nach der Publikation einer wichtigen Verletzlichkeit und hinreichenden Informationen sind drei Akteure gefordert, eine potentielle substantielle Risikoerhöhung zu identifizieren: Die IT-Security Experten einer Institution, die Verantwortlichen des Paketierungs- und Deploymentsystems in gemanagten Umgebungen sowie die IT-Verantwortlichen von Umgebungen mit erhöhtem Schutzbedarf. Das Paketieren und Ausliefern von Workarounds muss vorbereitet und eine Auslöseschwelle diskutiert werden.

Damit wird eine Beobachtungsphase eröffnet. Täglich müssen Verbreitung der Malware, Kontaktwahrscheinlichkeit und Widerstandfähigkeit der eigenen Maschinen betrachtet und gefragt werden, ob für die nächsten Arbeitstage ein Überschreitung des akzeptablen Risikos zu erwarten ist. Wenn ja, muss das Deployment von Workarounds oder andere risikomindernde Massnahmen angesetzt werden. Sofern nicht der Patch bereits angekündigt ist.

* * *
Es gibt durchaus Möglichkeiten, Zero Day Situationen professionell zu handhaben. Es erscheint nützlich, dass sich die betroffenen Stellen ein schlichtes Beurteilungsschema und Prozessdesign entwickeln, auch wenn ein ‚Ernstfall‘ sich nur selten einstellt. Ein Effizienzgewinn resultiert dann, wenn unnötige Aufregungen, Funktionseinschränkungen und Paketierungsaktivitäten vermieden werden können.

Serie Zero Day – Teil  3

Der Beitrag von Zero Day Situationen zum Risikovolumen wird eher überschätzt. Warum sie sich zu emotionaliserter Berichterstattung durch die Tagespresse eignen, haben wir im letzten Beitrag dargelegt. Ignoriert werden können sie aber auf keinen Fall. Wie lässt sich ihre Bedeutung fassen? Wer muss sich damit auseinandersetzen?

Wenn wir in der Geschichte fünf, sechs Jahre zurückblättern, sehen wir eine Welt mit vielen ‚naiv‘ konfigurierten PCs. Sie hatten keinen Firewall und publizierten Services (etwa freigegebene Ordner) direkt ans Internet. Das machte epidemieartige Infektionen möglich. Innerhalb weniger Stunden konnten im Direktkontakt hunderttausende von Maschinen angesteckt werden. Da war Alarmstimmung in Zero Day Situationen durchaus berechtigt. Seit der Verbreitung von XP SP2 ist die Mehrheit der Rechner am Internet durch Firewall geschützt. Auch verletzliche Maschinen werden nun durch indirektere Mechanismen infiziert, zB Besuch eines kompromittierten Websites.

Die Welt der IT wird immer differenzierter. Auch von Zero Day Situationen sind verschiedene Player unterschiedlich betroffen. Die Hersteller von Software sind bei jedem Hinweis auf Verletzlichkeiten herausgefordert, das Problem zu analysieren, das Risikopotential zu benennen, auf Workarounds hinzuweisen und Patches zu publizieren. Dabei ist es von institutionellen Kunden her dringend erwünscht, dass das in einem berechenbaren Schema erfolgt. Ein ausserterminliches Deployment ist dann angebracht, wenn die Risiken kurzfristig über ein tolerierbares Mass zu steigen beginnen.

Endanwenderinnen und Privatuser sollten sich um Zero Day Situationen nicht kümmern, sondern ihre sehr beschränkten Ressourcen darauf konzentrierten, ein paar einfache Bausteine der IT-Sicherheit in Schuss zu halten. Hier findet die grosse Risikoreduktion statt.

Für IT-Verantwortliche im Nebenamt mit sehr limitierten Ressourcen gilt das gleiche. Sie haben nicht die Zeit und die Infrastruktur, um situativ zu agieren und heute einen Workaround zu verteilen, morgen einen andern Browser bei ihren KollegInnen zu installieren, übermorgen alles wieder rückgängig zu machen und dann den endlich erschienenen Patch zu installieren. Je geringer die Ressourcen, umso eher sollten diese auf die Basics konzentriert werden.

Gemangte Umgebungen mit Standardqualität sind von Zero Day Situation nur am Rande betroffen. Weil Zero Day das Risikovolumen nur vorübergehend und allenfalls um wenige Prozent erhöhen, gilt als Faustregel: Das Deployment von Workarounds und andere situative Aktionen erübrigt sich, ohne dass die Qualitätsziele gefährdet werden. Ausgenommen sind Spezialsituationen, wo zB ein krasses Versagen eines Herstellers sich mit besonderer Exposition eines Userumfelds kombiniert.

Gemanagte Umgebungen mit erhöhtem Schutzbedarf müssen sich um wichtige Zero Day Situationen kümmern, indem sie diese einschätzen und mit der eigenen Risikotoleranz vergleichen. In den meisten Fällen drängt sich weder ein Deployment von Workarounds noch andere risikomindernde Massnahmen auf. In bestimmten Fällen kann das erwartete Risiko für die nächsten fünf Arbeitstage die Toleranzschwelle erreichen. Dann sind risikomindernde Schritte zu prüfen, die in verschiedene Richtung gehen können: Implementierung eines temporären Workarounds oder Funktionalitätsbeschränkungen auf der Maschine; Erlass von temporären Verhaltenseinschränkungen an die Enduser; Limitieren der Kontaktrisiken mit Malware, indem etwa ein Webproxy temporär den privat motivierten Kontakt zu Websites einschränkt.

Im Kontext der gemanagten Umgebungen sind die Betreiber der Deployment-Infrastruktur besonders herausgefordert. Wenn die Verantwortlichen von gemanagten Umgebungen plötzlich einen Workaround verteilen wollen, muss dieser paketiert und getestet im Deploymentsystem bereit liegen. In Abstimmung mit diesen Kunden muss der Deployment Provider stufenweise und abhängig von der Risikosituation in die Bereitstellung einsteigen. Das ist anspruchsvoll, weil die Vorlaufzeit noch grösser ist als für den direkten IT-Verantwortlichen, der unmittelbar die Entwicklung der nächsten paar Tage abschätzen muss.

Kurz: Enduser sollen sich in Ruhe auf ein paar Basics konzentrieren – die Verantwortlichen für betriebliche Umgebungen mit erhöhten Qualitätsanforderungen müssen Zero Day Situationen in ihr generelles Risikomanagement einbauen. Als Bezugspunkt können allgemeine Lagebeurteilungen genommen werden, wie sie an der ETH für jede Betriebssystemfamilie aktualisiert werden.  Für die Festlegung der Risikotoleranz und für die Beurteilung der konkreten Risiken vor Ort sind die betrieblichen Verantwortlichen zuständig.

Serie Zero Day – Teil 2

Zero Day Situationen sind nichts für schwache Nerven. Die Vorstellung einer bestimmten ungepatchten Verletzlichkeit scheint sich gut zum Hochkochen von Emotionen zu eignen. Statt sich täglich mit Qualitätssicherung herumzuplagen ist es natürlich einfacher, von Zeit zu Zeit etwas Aktivismus zu entfalten. Jedenfalls haben Zero Day Situationen in den letzten Jahren bei IT-Hobbyisten wie Profis unangemessen hohe Aufmerksamkeit genossen – auf Kosten wirklich relevanter Qualitätsverbesserungen. Warum? Hier einige Hintergründe.

Paranoia. Die Vorstellung einer vorerst „unheilbaren“ Verletzlichkeit im PC scheint mit schweren unheilbaren Krankheiten vergleichbare Vorstellungen zu aktivieren. Wie gross die reale Risikoerhöhung gegenüber dem ständigen Backgroundrisiko ist, interessiert kaum.

Bashing. Einem grossen Konzern einen nicht sofort behebbare Fehler nachzuweisen ist eine wunderbar emotionalisierte Anomalie. Solche Situationen sind bestens geeignet, um verdeckte Agendas zu verfolgen und sein eigenes Weltbild zu stabilisieren.

Publizistik. Nicht nur die Tagespresse sondern auch die Computerheftli wissen, dass viele ihrer LeserInnen lieber emotionalisiertes Kurzfutter lesen, als nüchterne Problemanalysen. Der Presse kann das nicht zum Vorwurf gemacht werden. Eine andere Frage ist, ob auch professionelle Milieus so ticken sollen.

Green IT. IT ist grün im Sinne einer unreifen, sich wild entwickelnden Technologie. Das macht diese Branche so spannend. Entsprechend grün wirkt dann halt in manchen Teilen auch die professionelle Kultur. Hier sind private Haltungen und diffuse Argumente in einem Ausmass präsent, wie dies in reiferen Bereichen wie etwa dem Maschinenbau kaum denkbar ist. So fehlt etwa ein fachlicher Konsens, wie für einen Maschinenpark Risiken zu bewerten und zu managen sind.

Impressionismus. Wo eine auch nur skizzenhafte Vorstellung von Risikomanagement fehlt, wird eine Umgebung anfällig für zufällige und publizistisch hochgekochte Einzelfälle.

Ressourcenmangel. In manchen Hochschulumgebungen ist das der zentrale Background. Die IT-Verantwortlichen werden gelegentlich derart knapp gehalten, dass an das Erarbeiten und Umsetzen einer konsistenten Strategie nicht zu denken ist. So wird eine reaktive Haltung geradezu erzwungen.

CERTismus. In der IT Security haben reaktive Muster aufgrund historischer Umstände weiterhin übermächtiges Gewicht. Die erste relevante Institutionalisierung ist in Form von Reaktionszentren erfolgt – Computer Emergency Respons Teams CERT. Das war aus dem Nichts ein grosser Fortschritt, entspricht aber nicht mehr den Anforderungen des Internet-Zeitalters. Nun geht es zentral um das proaktive Handhaben und Reduzieren von Risiken. Die Maschinen müssen widerstandfähig und die User risikobewusst werden.

Serie Zero Day – Teil 1

Eine Zero Day Situation entsteht, wenn zu einer momentan nicht patchbaren Verletzlichkeit Malware am Horizont erscheint. Wie ist die so entstehende Lage zu bewerten und einzuordnen?

Der Begriff Zero Day wird üblicherweise im Zusammenhang mit Exploit verwendet. Ein Exploit ist eine Arte Demoprogramm, das die Ausnutzbarkeit einer Verletzlichkeit dokumentiert.

Die so belegte Ausnutzbarkeit klärt einen Aspekt einer Verletzlichkeit. Das heisst, die Verletzlichkeit ist nicht nur theoretisch ein Problem, sondern technisch prinzipiell ausnutzbar. Die Relevanz einer Verletzlichkeit rutscht eine Stufe nach oben.

Allerdings klärt die Existenz eine Exploits noch nicht die Frage, ob eine in der realen Welt funktionierende Malware möglich ist und welche Verbreitungschancen sie hat. Die Abschätzung des Risikopotentials bleibt schwierig.

Teilmenge von ungepatcht

Aufgrund der Unsicherheit und des Mangels einer simplen Lösung sorgen Zero Day Situationen für Aufmerksamkeit. Ihre Bedeutung wird häufig überschätzt und muss darum im Kontext diskutiert werden. Zero Day Situationen sind nur eines von verschiedenen Szenarien der Kategorie „ungepatchte Verletzlichkeit“:

1) Unbekannt: Weder bekannt noch genutzt. Betriebssystem und Anwendungen enthalten Dutzende bis hunderte von Verletzlichkeiten, die zu einem bestimmten Zeitpunkt niemandem bekannt und von niemandem genutzt werden.
2) Selektiv: Nicht öffentlich bekannt, von diskreten Akteuren genutzt. Einzeltäter, organisiertes Verbrechen, Privatdetektive und staatliche Dienste versuchen, unbekannte Verletzlichkeiten zu finden und selektiv über Monate oder Jahre auszunutzen.
3) Zero Day: Öffentlich bekannte momentan patchlose Verletzlichkeit mit Zero Day Exploit oder Zero Day Malware. Zeitlich begrenzte Situation, wo eine Verletzlichkeit mangels Patch nur Workarounds begrenzt werden kann.
4) Ungepatcht: Ungepatcht trotz publiziertem Patch. Aufgrund mangelnder Systempflege dürften weltweit mehrere hundert Millionen Systeme in diesem Zustand am Netz operieren.
5) Veraltet: Ungepatcht weil nicht mehr patchbar. Verletzlichkeiten bleiben offen, weil veraltete Versionen von Betriebssystem und Applikationen verwendet werden, die gar nicht mehr mit Patches unterstützt werden.

Relevanz

Generell wird das Gewicht von Zero Day Situationen im Vergleich zu anderen Risiken überschätzt. Auf die Gründe werden wir in einem weiteren Beitrag eingehen. Ausgehend von den Erfahrungen an der ETH Zürich lässt sich die Bedeutung der verschiedenen Szenarien für Windows Kompromittierungen wie folgt zusammenfassen:

a) Für rund 95% der Vorfälle ist das Nicht-Installieren existierender Patches oder die Verwendung veralteter Software verantwortlich. Das hat nichts mit Zero Day zu tun.

b) Für etwa 5% der Vorfälle in den letzten Jahren sind Zero Day Situationen verantwortlich. Eine Ausnahmesituation herrschte im Frühsommer 2010, wo nicht patchbare Adobe Reader und Flash Verletzlichkeiten eine Menge Kompromittierungen zur Folge hatten.

Völlig zu Recht weisen secunia und Publikationen wie heise online darauf hin, dass ungepatchte Applikationen zum Hauptrisiko geworden sind. Adobe rückt aufgrund der zahlreichen Lücken und der weiten Verbreitung der Produkte ins Zentrum der Aufmerksamkeit. Auf einem aktuellen Windows PC bilden Flash und Adobe Reader die Hauptpforte für den Eintritt von Malware beim Besuch verseuchter Websites.

Firmen wie Adobe verdienen die Aufmerksamkeit und Unterstützung der IT-Community. Sie bilden wichtige Bollwerke gegen eine völlige Monopolisierung von Applikationen und Content durch die nimmersatten Trampeltiere Apple, Google und Microsoft. Allerdings ist jede Rücksichtnahme kontraproduktiv, wenn sich etwa Adobe in Sachen Security suboptimal verhält: Bereits heute ist der Trend feststellbar, dass verunsicherte User und Admins sich unter den Schirm eines grossen Imperiums flüchten und möglichst alles aus einer Hand beziehen wollen, nachdem sie sich mit unsicheren Produkten von Drittanwendern und Open Source Communities die Finger verbrannt haben. Dieser Trend spielt momentan zu Gunsten von Apple, in einigen professionellen Umgebungen aber auch zugunsten von Microsoft.

Adobe leistet sich verschiedene Suboptimalitäten in Sachen IT-Security.

Inzwischen ist die Notwendigkeit einer Life Cycle Pflege der Produkte bei Adobe erkannt und es wurde ein Schema etabliert, das aber nicht angemessen ist. Ein reguläres Patching nur alle drei Monate vorzusehen, ist problematisch bei den vielen Verletzlichkeiten. Folgerichtig musste jüngst Adobe bereits das Schema brechen und wichtige Verletzlichkeiten kurz vor dem regulären Termin schliessen.

Wenig bekannt und begeisternd ist, dass Adobe dem User zwangsweise weitere Applikationen installiert, wenn dieser bloss Adobe Reader und ein Flash Plugin haben möchte. Der aufmerksame Windows User findet folgendes in seiner Programmverwaltung:

Adobe AIR ist ein eigentliche Anwendungsumgebung wie Java oder .NET. Damit schafft Adobe eine Infrastruktur für das browserlose Laufenlassen von Adobe Apps. Adobe.com – ein unsäglich verwechslungsträchtiger Name – scheint ein Konferenzprogramm zu sein. Beides mögen nette Dinge sein – für den Durchschnittsuser sind sie einfach unerwünschte neue Risiken.

Es fehlt ein Adobe Security Center, das auf einen Blick die vorhandenen Komponenten und ihren Security Status zeigt und verwaltet. Adobe würde es aber auch gut anstehen, die Initiative zu einer „Application Patching Platform“ zu ergreifen, in welche App Lieferanten ihre Patches einspeisen könnten.

Auf der Testseite für Flash Plugins muss der User „von Hand“ die detektierte Version mit einer Liste vergleichen, statt dass gleich eine Warnung und die Möglichkeit zum Update gezeigt wird.

Adobe wäre gut beraten, in Sachen Security mehr Dampf aufzusetzen, wenn es in sich in fünf Jahren nicht in einer marginalen Nische wiederfinden will.

Seit etwa 2007 verbreiten sich Varianten von Gozi auf Windows Rechnern und sammeln dort Account Informationen. Der professionell designte Trojaner zielt auf Bankkunden, taucht aber in den letzten Wochen auch häufiger an Hochschulen auf.

Gozi kann vor allem den Anwendern und Admins richtig wehtun. Den Usern können eBanking- und andere Konten ausser Kontrolle geraten. Admins sind mit einer Malware auf dem Stand der Technik konfrontiert, die auf dem System schwierig zu anaylsieren und unter Kontrolle zu bekommen ist.

Gozi kann verschieden Versionen von Windows befallen. Unter XP betrieben unter Admin-Rechten installiert er sich auf Ebene des Systems. Unter Windows7  wo der User out of the Box mit Standarduserrechten arbeitet, im Userkontext respektive Userprofil, ohne dass der Kern des Systems kompromittiert wird. Diese und weitere Infos sind rein indikativ, solange keine konsistente technische Analyse der Malware inklusive Versionshistory greifbar ist!

Ansehen…

Um eine Befallshypothese zu prüfen, kann unter XP etwa der folgende Registry-Eintrag angesehen werden, der auf ein Gozi DLL zeigt – zumindest bei einzelnen momentan aktuellen Varianten: Ein Fehlen dieses Eintrags bedeutet nicht dass ein System Gozi-frei ist!
HKLM\System\CurrentControlSet\Control\SessionManager\AppCertDlls

Unter Vista/W7 kann der der Autostart-Pfad lauten:
HKU\{UserSID}\Software\Microsoft\Windows\CurrentVersion\Run\lsasasrv:
“rundll32″C:\Users\{UserName}\AppData\Local\Temp\fontnatt.dll”,DllEntryPoint”

Detektion mit AV: Auch führende Produkte wie Avira von der Rescue CD erkennen aktuelle Mitglieder der Gozi-Familie nicht (immer). 

… und Aufräumen

Eine befallene Box sauber zu bekommen heisst: Neuinstallation. Ausnahmen können sich nur qualifizierte Profis genehmigen – unter ein paar Bedingungen:

• Es sind tiefe Systemkenntnisse verfügbar, um versteckte Systemmechanismen detektieren
• Es ist klar, welche Malwareversion vorliegt, sodass entsprechende Removal-Tips wirklich zutreffen
• Es kann analysiert werden, dass keine weitere Malware auf dem System existiert

Kurz und gut: Weder ein Virenscan noch das Abarbeiten eines Removal Tips garantieren ein porentief reines System.

Prävention

Mögen die Wege von Gozi in das System noch so raffiniert sein – sie nützen Verletzlichkeiten aus. Waren das in früheren Jahren solche des Internet Explorer, sind das nun zB ungepatchte Löcher des Adobe Readers: „We witnessed a number of Gozi Trojans distributed via malicious PDF versions.“ Stellt eine Analyse der TrustDefender Labs fest.

Gozi Prävention heisst wie immer: Nicht nur Windows, sondern auch Anwendungen und Plugins ständig auf die neueste Version upgraden und alle Patches einspielen.

Ein Virenschutz mit aktuellen Definitionen ist hilfreich, kann aber Patchen nicht ersetzen. Gerade Gozi Varianten bleibt durch die Verwendung neuer Techniken häufig wochenlang durch verschiedene Virenscanner unentdeckt. Das gilt auch für HiEnd Produkte von Symantec oder Avira, welche eine neuere Version unter dem Label TR/Spy.Banker.Germ.A führt.

Informationen

Einen guten neueren Überblick bietet Gozi – a perfect example of an “older” trojan re-inventing itself der bereits erwähnten TrustDefender Labs.

Historische Analyse von SecureWorks  2007.

Beispiel für die Beschreibung einer bestimmten Instanz durch eine AV-Firma ist TR/Spy.Banker.Germ.A – Trojan von Avira. Etwas müde Sophos, letzte Update im Januar – hier heisst der Trojaner Troj/Gozi-Gen und es werden Aliases aufgeführt: Trojan.Win32.Agent.cbr und Generic PWS.o .

Der Secunia Personal Software Inspector PSI leistet ausgezeichnete Arbeit beim Aufspüren von nicht gepatchten Applikationen auf einem PC. Momentan leistet er sich aber zwei problematische Fehlalarme, die Benutzer unnötig verunsichern und Aufwand verursachen.

Im Advanced Mode meldet der PSI “Adobe Flash Player 10.x is insecure”. Mit der Bemerkung “we recommend that you update or uninstall all programs listed here” wird der Eindruck vertieft, dass die installierte Flash Version nicht aktuelle sei – was so nicht zutrifft. Ursache des Fehlalarms: Ein File einer früheren Installation lagert noch auf dem PC und wurde offenbar vom Adobe Installer nicht entfernt.

Ganz unzutreffend ist eine Warnung zu Office PowerPoint Viewer 2007. Die Warnung erscheint auch, wenn die Komponente gar nicht installiert ist! Selbstverständlich soll und darf Microsoft Update nicht Komponenten neu installieren, die nicht da sind (von Update kann ja keine Rede sein).

Schlussfolgerung: Standarduser sollten sich sich aufs Wesentliche – und damit auf die Ansicht “Simple” konzentrieren. Im “Advanced” Modus muss man sich die Zeit nehmen, den einzelnen Anomalien nachzugehen. Vorbildlich von Secunia: Ein Link zum betroffenen Ordner und zu weiteren Infos wird angeboten.

Virenschutz ist nur einer von mehreren Faktoren der PC-Sicherheit. Unverzichtbar bleibt er. Im der Nummer 26/2009 hat c’t einige aktuelle Virenschutzprogramme getestet – es fehlen die an der ETH wichtigen Produkte von Avira (letzter Test in c’t 12/2009) und Sophos.

Als Leitindikator betrachten wir die Erkennungsrate eines Malware Zoos mit einer
Halben Million Schädlingen. Die Begründung: Wer mit den paar hunderttausend weit verbreiteten Malwares aus den letzten Monaten nicht zurecht kommt, kann dieses Loch unmöglich durch andere Stärken kompensieren. Bemerkenswert ist, dass die meisten Produkte nun diesen Zoo viel besser handhaben als vor zwei Jahren. Die Ergebnisse führen zu folgenden Bewertungen. McAfee stösst mit der Edition 2010 in die Spitzengruppe vor. Microsoft Security Essentials macht als kostenloser Neuankömmling einen sehr guten Eindruck. 

Die guten Erkennungsraten geben Spielraum, weiteren Gesichtspunkten wie Usability oder dem Vorhandensein einer Konsole für betriebliche Umgebungen mehr Platz einzuräumen. Hier nun einige Zoo-Erkennungsraten aus c’t:

Weitere Daten finden Sie bei CHIP - Avira macht in diesem Test 2010 nicht den gewohnten brillianten Eindruck – es sollte aber die mittelfristige Performance über mindestens 2-3 Jahre betrachtet werden. Eine gewisse Formschwäche von Avira zeigt sich auch in den Testergebnissen von av-comparatives. Alle relevanten Produkte sind auf einem reaktiv/proaktiv Diagramm von virusBULLETIN eingetragen – diese Ergebenisse stützen die folgenden Empfehlungen.

Empfehlungen

Referenzprodukt bleibt Avira Antivir aufgrund seiner jahrelang hohen Erkennungsleistung, Aktualisierungsperformance und Supportqualität. Ebenfalls in die Topkategorie reihen wir Norton AntivVirus ein.

Als gute Produkte viel besser als gar nichts sehen wir: McAfee AntiVirus, das aufgrund der schlechten Leistungen in den letzten Jahren (zB eine Erkennunsrate von nur 86.4% 2008) mit einem Makel behaftet bleibt. Sophos, das schwer beurteilbar ist, weil es kein Retail-Produkt vertreibt, das von c’t und anderen getestet wird. Microsoft Security Essentials ist einfach noch zu jung, um fundiert beurteilt zu werden – erste Wahl, wenn es nichts kosten darf, etwa für sporadisch verwendete Virtuelle Maschinen. Avira Free kommt für alle in Frage, die sich an Werbeeinblendungen nicht stören.

Mit der wachsenden Beliebtheit von USB-Sticks und mobilen Harddisks sind diese Medien zu immer wichtigeren Verbreitungsmitteln für Malware geworden. In bester Erinnerung ist Conficker, der unter anderem auf diese Verbreitungsmöglichkeit hin ausgelegt war.

Bekannt ist, dass ursprünglich mit Hilfe von autorun.inf auf dem Stick nach dem Einstecken direkt eine Software gestartet werden konnte – wenn die Systemkonfiguration es zuliess. Weniger bekannt ist, dass auch der Userdialog gestaltet werden konnte. Das geht auf ein traditionelles Feature zurück, das ein komfortables Startmenu etwa auf Installations-CDs erlaubt. So konnte auch vom Stick im öffnenden Dialogfenster zB ein Menupunkt „Open Folder to view files“ mit Icon eingeblendet werden, der wie vom System geschaffen aussah. Ein Klick darauf öffnete nicht den Folder, sondern startete direkt die Malware.

Diese Möglichkeit ist bei Windows 7 für USB-Sticks eliminiert worden. Der Dialog stammt ausschliesslich vom System – gefälschte Einträge sind ausgeschlossen. Das verhindert natürlich nicht, dass User auf dem Stick browsen und per Maulklick und Bestätigung eine Malware starten. Ein Blog-Eintrag erläutert das.

Für Windows Vista und XP wird diese Beschränkung mit dem Patch kb 971029 installiert.

Info zum Feature AutoRun-Enabled Application. KB 967715 liefert Information zum Wegschalten und Konfigurieren von Autorun. Das für Vista dokumentierte gilt auch für Windows 7. Die mit gpedit.msc setzbaren Parameter werden auch direkt in der Konsole dokumentiert.   

Mit der Anbindung eines Computers ans HiSpeed Internet geht ein massiver Angriffsdruck einher. Die Widerstandfähigkeit eines PCs muss optimiert werden. Wir wollen uns einen kurzen Überblick verschaffen, welche Elemente die Qualität und Sicherheit eines Hosts prägen. Ein Schichtenmodell schafft Übersichtlichkeit, um Handlungsspielräume zu identifizieren und einzelner Technologien zu verorten.

Im Zentrum steht ein einzelnes System mit seiner Software in einer konkreten Konfiguration. Hinzu kommen zwei angrenzende Schichten – die Produktion des Betriebssystems und das Userverhalten.

Spezifikation und Qualitätssicherung bei der Entwicklung und Publikation des Betriebssystems. In diesem Prozess werden entstehen nicht nur die Security-Features eines Betriebssystems. In Scheinwerferlicht ist in den letzten Jahren auch die Codequalität gerückt. Die Zahl der Bugs und Verletzlichkeiten soll beim Release des Betriebssystems möglichst gering sein. Microsoft und Adobe haben in den letzen Jahren entsprechende Prozesse aufgesetzt.

Betriebssystem Architektur und Sicherheits-Basismechanismen. Zum architekturalen Design gehört die Aufteilung der Komponenten für Usermode und Kernelmode, Authentisierungsmechanismen und vor allem ein konsistentes Modell von Objektsicherheit.

Sekundäre Schutzmechanismen des Betriebssystems. Darunter fassen wir Mechanismen, die ein Ausnützen von Schwächen und Verletzlichkeiten verhindern oder die Auswirkungen limitieren. Dazu gehören Mechanismen wie DEP (Data Execution Prevention) oder ASLR (Address space layout randomization).

Tertiäre Schutzmechanismen des Betriebssystems bieten dem User Warnungen und Wahlmöglichkeiten etwa beim Einbringen von lauffähigem Code auf das System. Zu dieser Gruppe zählt auch UAC (User Account Control) welche das Arbeiten und Standarduser respektive Adminrechten moderiert.

Konfiguration des Betriebssystems. Der Hersteller liefert das Betriebssystem mit einer bestimmten Defaulteinstellung aus. User respektive Admins können aber tausende von Parametern einstellen respektive über Policies einer Gruppe von Systemen aufprägen. Die konkrete Konfiguration eines Systems beeinflusst ganz wesentlich das Risikopotential eines Systems.

Applikationsqualität insbesondere bei Programmen mit Internetkontakt wie Webbrowser ist eine wichtige Determinante von Hostqualität.

Virenschutz. Es gilt ähnliches wie für die sekundärensch Schutzmechanismen – in einer Welt perfekter Systeme wäre er überflüssig.

System Firewall. Schirmt das System vor unerwünschten Aushorchung und Kontakten ab.

Userverhalten. Je grösser der Möglichkeitenraum eines Systems ist, welcher durch die Konfiguration vorgegeben wird, umso stärker hängt die Sicherheit des Systems vom Verhalten des Users ab. Gleiches gilt für die verschiedenen Ebenen von Schutzmechanismen: In dem Masse, wie diese fehlen, veraltet oder disfunktional sind, wächst das Risiko bei jeder Aktion des Users.

Host-Security als Schichtenmodell: