scaryBITS

Was secunia vor Monaten angekündigt hat, wird nun schrittweise umgesetzt: Der Personal Software Inspector 2 kann Patchingbedarf nicht nur identifizieren, sondern auch Patches installieren.

Die soeben veröffentlichte Betaversion patcht vorerst nur eine Minderheit der analysierten Programme. Trotzdem zeichnet sich hier für Private User und Kleinbetriebe eine Möglichkeit ab, rationeller einen akzeptablen Patching Stand zu erreichen.

Der Zeitpunkt könnte nicht günstiger sein. Die aktuellen DLL Loading Risiken sind bei zahlreichen Applikationen identifiziert worden. In den nächsten Wochen und Monaten dürfte sich ein Schwall von Patches und Updates über die User ergiessen. Für die Betreiber von standalone PCs lohnt es sich, das neue Produkt genauer anzusehen.

Nachdem das Risikopotential des unsicheren DLL Loading jahrelang kaum Beachtung fand, wird es momentan intensiv diskutiert und untersucht. Damit entsteht ein Bündel von Zero Day Situationen.

Nun sind auch leicht handhabbare Tools und Methoden greifbar. Darum werden zahlreiche Anwendungen untersucht und schlagartig landen Dutzende von ihnen auf den entsprechenden Listen. Darunter auch solche von Microsoft, bei denen die Programmierer sich über die „good practices“ des Konzerns hinweg gesetzt haben. Bei Secunia dominiert nun „Insecure Library Loading Vulnerability” das Bild:

Secunia listet die betroffenen Applikationen auch in einer zusammenfassenden Liste.  Die Sicherheitsfirma bewertet die DLL Verletzlichkeiten der Applikationen als „highliy critical“. Dabei wird aber nicht spezifiziert, unter welchen Voraussetzungen die Verletzlichkeit ausgenutzt werden kann.

Bestimmt werden diese Verletzlichkeiten in die Malware-Baukästen Eingang finden. Die betroffenen ungepatchten Anwendungen werden auf Monate und Jahre hinaus auch über diese Verletzlichkeitskategorie angegriffen werden.

Es bleibt vorläufig offen, wie weit dieses Bündel von Verletzlichkeiten kurzfristig zu einem substantiellen Anstieg des Risikos führt.

Beim Programmieren von Anwendungen auf wiederverwendbare Komponenten zu bauen, hat sich durchgesetzt. Es entsteht dabei ein Risiko, wenn Angreifer eine Anwendung veranlassen können, eine manipulierte Komponente nachzuladen. Dieser Problematik wird seit Jahren diskutiert, im Fall von Windows beispielsweise hier.

Brisanter ist die Problematik geworden durch die Ausbreitung der Konnektivität und durch aktuelle Hinweise auf Exploits. Microsoft hat ein Advisory publiziert.

Beim dynamischen Laden von Komponenten sind zwei Szenarien zu unterscheiden. Entweder programmiert der Programmierer den Pfad zur Komponente. Das empfiehlt Microsoft als Good Practice, weil damit ein Laden von Malware-Komponenten unterbunden wird. Oder der Pfad wird offen gelassen, dann sucht das Betriebssystem nach einer vorgegebenen Liste in verschiedenen relevanten Pfaden nach der DLL. Einer dieser Pfade ist das aktuelle Arbeitsverzeichnis.

Dieses aktuelle Verzeichnis kann auch ein USB-Laufwerk, eine WebDAV Verbindung oder ein mit SMB eingebundenes Netzlaufwerk sein. Damit sind gleich die wichtigsten Verbreitungspfade angesprochen. Die Bedingungen für eine erfolgreiche Infektion sind:

1. Malware muss auf einem potentiellen Pfad eines Systems platziert sein, am einfachsten ein externes Medium.
2. Dieser Pfad muss der aktuelle Pfad sein.
3. Die Anwendung muss so programmiert sein, dass sie beim Öffnen bestimmter Filtypen das Betriebssystem nach noch nicht eingebundenen DLLs suchen lässt.

Nicht alle in der aktuellen Diskussion als verletzlich genannten Anwendungen verhalten sich gleich und schicken bei einem Standard-Filetyp das Betriebssystem auf DLL-Suche. Es kann durchaus sein, dass ein Media-Player bei jedem MP3 eine Suche anstösst, die ins aktuelle Verzeichnis führt. Beim von Secunia ebenfalls als verletzlich gelisteten PowerPoint zeigt andererseits ein kurzer Test mit Version 2010, dass das Öffnen ein *.pptx Files von einem Memorystick nicht zu einem DLL-Search auf diesem Stick führt. Eine allfällig vorhandene Malware würde nicht geladen. Die genauen Modalitäten der Ausnützbarkeit bleiben offen.

DLL Preload ist vorerst ein ernst zu nehmendes Potential, aber kein sich schlagartig auftürmendes Risiko. An der grundsätzlichen Ausnützbarkeit bestehen keine Zweifel. Ob das leicht in grossem Ausmass möglich ist, dürfte sich im Verlauf des Monats September zeigen.

Von den grossen Softwareproduzenten darf erwartetet werden, dass sie zügig Ihre Produkte analysieren und wenn nötig die Lademechanismen für DLLs abdichten.

Auf Ebene des Betriebssystems liegt keine Verletzlichkeit im üblichen Sinne vor. Für Umgebungen mit erhöhtem Schutzbedarf hat Microsoft einen Workaround publiziert, welcher die Einschränkung der Ladepfade möglich macht. Derartige Einschränkungen des Möglichkeitenraums haben häufig einen Preis. Im vorliegenden Fall werden bei einzelnen Programmen wie Google Chrome Kompatibilitätsprobleme gemeldet.

[Fortsetzung zum Thema DLL: Apps mit unsicherem DLL Loading]

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.

Seit der letzten Marktbetrachtung ist wieder etwas Zeit verflossen und die Lage verändert sich ständig. Offenbar hat Asus in den letzten Monaten Apple als Nummer 6 im globalen PC/Laptop Markt überholt. Das zeigen die Zahlen von IDC, wo der Mainboardhersteller aufgrund seiner Erfolge bei Nettops in der Top 5 Liste erscheint – prozentual gleichauf mit Toshiba. Mit 3.47 Mio. verkauften Mac hat Apple einen Anteil von 4.3% am Weltmarkt, wo in diesem Quartal 81.5 Mio. Rechner abgesetzt wurden. Das ist weder für Apple und schon gar nicht für seine Aktionäre ein Problem. Der sehr profitable Konzern ist aus der IT-Branche hinaus in den Top Level Bereich der elektronischen Konsumgüter hinein gewachsen.

Bemerkenswert ist der Aufstieg von Lenovo. Asien weist sehr viel höhere Wachstumsraten auf als die USA und Europa. Lenovo hat die günstige Situation auf dem Heimmarkt effizient genutzt.

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 .