TC Blog

Java deaktivieren? Ja, bitte!

Oracle hat sich mit Java wohl ein Bärendienst erwiesen. Bereits zum wiederholten Mal ist dieses Jahr eine Schwachstelle in Java gefunden worden, die sich leicht ausnutzen lässt.

Und so sieht das ganze in der Praxis aus. Es reicht, eine Seite mit entsprechendem Schadcode aufzurufen. Die einzige Gegenmaßnahme ist derzeit tatsächlich, Java zu deaktivieren oder gleich ganz zu deinstallieren.

• Java in Firefox deaktivieren: Extras->Addons->Plugins->Java->Klick auf “deaktivieren”
• Java in Chrome deaktivieren: Chrome fragt (derzeit) immerhin bei jedem Aufruf nach. Um sicher zu sein chrome://plugins/ eingeben und Java in der Liste deaktivieren
• Java im Internet Explorer deaktivieren: Extras->Internetoptionen->Sicherheit->Stufe anpassen->Scripting von Java-Applets->Deaktivieren

Testen lässt sich die aktuelle Befindlichkeit des Browsers im heise Browsercheck.

Nur bekannte Seiten anzusteuern reicht als Sicherheitsmaßnahme im Übrigen niemals aus, es droht immer die Gefahr durch Drive-By-Downloads.

/gt

NFC ermöglicht Bluetooth-Pairing u. A. – Charlie Miller zeigt es auf der Black-Hat

Neuere Smartphones gibt es derzeit in rund 50 Endgeräten, vor Allem in den aktuellen Android-Topmodellen wie dem Samsung Galaxy S III oder HTC One X, aber auch in Geräten wie dem Nokia N9 auf Basis MeeGoo.

NFC ermöglicht die drahtlose Kommunikation aus Kurzdistanz und ist vorgesehen u. A. für Micropayment-Anwendungen, also dem drahtlosen Bezahlen von kleinen Beträgen.

Dass NFC-Implementierungen Fehler haben werden ist klar, Charlie Miller zeigt als erster konkrete Angriffe im Rahmen der diesjährigen Black-Hat Sicherheitskonferenz in Las Vegas. In seinem Vortrag Don’t Stand So Close To Me: An Analysis Of The NFC Attack Surface zeigte er unter anderem wie ein Angreifer auf einem in der Nähe befindlichen Telefon eine beliebige Webseite im Browser aufrufen oder per NFC eine Bluetooth-Verbindung herstellen zu können. Damit geht dann nun wirklich fast alles.

Schade ist es wieder zu sehen, wie langsam bzw. gar nicht die Hersteller auf diese Schwachstellen reagieren. Laut Miller hat sich Google bisher überhaupt nicht geäußert, die strauchelnde Nokia nimmt natürlich “Sicherheit sehr ernst” und ist sich “der Analysen bewusst” und “untersucht das Problem”. Nunja.

/gt

M 2.300 Sichere Außerbetriebnahme oder Ersatz von Komponenten eines Sicherheitsgateways

Die Aussonderung von Geräten ist ein oft vernachlässigter Schritt im Lebenszyklus von IT-Systemen. Gerade bei Sicherheitsgateways oder Routern, aber auch bei anderen IT-Komponenten ist dies äußerst wichtig.

Der jüngste Vorfall zeigt recht deutlich, wie wichtig es ist, dass Geräte vor der Aussonderung von Restinformationen befreit werden.

Oft wird bei der Aussonderung nur an eine Entschriftung der Geräte oder an die Unbrauchbarmachung durch Kurzschluss der Netzteile (o. Ä.) gedacht. Eine Entschriftung alleine ist völlig unzureichend und mit etwas Aufwand kann man auch an die Daten im Gerät kommen, selbst wenn es kurzgeschlossen wurde. Vielmehr sollten weitere Aspekte berücksichtigt werden, so z. B.:

• Factory-Reset: Löschen aller Daten (Konfiguration, Logs, temporäre Daten, Schlüssel und Passwörter). In Sicherheitsgateways finden sich für potentielle Angreifer wichtige Informationen! „Die Vorgehensweise hängt dabei stark von der Art und vom Verwendungszweck des Gerätes ab. In der Sicherheitsrichtlinie für das Sicherheitsgateway sollten hierfür entsprechende Verantwortlichkeiten definiert werden.“ (Zitat aus dem Maßnahmentext)
• Prüfen, ob Restinformationen nach einem Factory-Reset noch vorhanden sind und nicht durch diesen gelöscht wurden. Falls nicht bereits geschehen sollten diese Informationen ebenfalls gelöscht oder durch mechanische Zerstörung gänzlich unbrauchbar gemacht werden.
•  (Wechsel-)Medien sollten aus dem Gerät entnommen werden und gesondert behandelt werden (hierfür gibt es einen eigenen Baustein).
• Ist ein Factory-Reset oder die Entnahme von Datenträgermedien nicht möglich, so sollten diese nach Möglichkeit mechanisch zerstört werden.

Weiterhin ist aber auch wichtig, dass bei einer (Teil-)Ersetzung bzw. Aussonderung der Komponentenlandschaft die Konfiguration der verbleibenden Komponenten dahingehend angepasst wird, dass die Nutzung der Konfigurationsdaten oder Schlüssel der gelöschten oder zerstörten Geräte (mögen sie in Frieden ruhen ) nicht mehr Nutzbar sind.

Die Aussonderung ist jedoch nicht nur bei Sicherheitsgateways wichtig, sondern bei allen IT-Systemen oder Daten. Weitere Hinweise hierzu können aus der Maßnahme M 4.234 Geregelte Außerbetriebnahme von IT-Systemen und Datenträgern entnommen werden.

Haben Sie die Aussonderung von IT-Komponenten in Ihren Komponentenlebenszyklus eingebettet? Deckt er bei Ihnen die wichtigen Aspekte vollständig ab?

Weitere Hilfe

Haben Sie überdies noch Fragen oder benötigen Beratung bei der Anpassung Ihrer Prozesse, so nehmen Sie einfach und unverbindlich Kontakt mit uns auf. Wir Beraten Sie gerne.

/sb

P.s.: dieser Post soll kein Fingerzeig in irgend eine Richtung sein, sondern soll vielmehr verdeutlichen, dass Maßnahmen der IT-Grundschutzkataloge Ihre Daseinsberechtigung haben.

Sicherheitspaket für Windows Server 2008 R2 fertigestellt

Nach den Veröffentlichungen der Sicherheitspakete für die Clients (Windows 7 und Windows XP), Server (Windows Server 2003) sowie des kostenlosen Sicherheitspakets für Browser wurde nun auch das Sicherheitspaket für Windows Server 2008 (R2) fertiggestellt. Dabei wurde wieder die gleiche Vorgehensweise wie bei Windows 7 verfolgt. Die Anforderungen der Grundschutzkataloge des Bundesamts für Sicherheit in der Informationstechnik (BSI) wurden um die Inhalte der Microsoft Security Baselines ergänzt.

Da Microsoft die Windows Server 2008 R2-Version im Kern immer noch auf Windows Server 2008 basiert, sind die technischen Anforderungen auf beide Versionen anwendbar. Unterschiede gibt es natürlich trotzdem, diese betreffen aber hauptsächlich Detailverbesserungen wie Stromsparfunktion, DirectAccess, BrancheCache und ein verbessertes Rollenkonzept.

Als Information zur Umsetzung der Vorgaben der Grundschutzkataloge sollte erwähnt werden, dass die Vorgaben des BSI für die Betriebssysteme Windows Server 2003 (B 3.108) und der Allgemeine Server (B 3.101)  nach bestem Wissen auf Windows Server 2008 angewendet wurden, da Windows Server 2008 leider noch nicht Teil der aktuellen Grundschutzkataloge ist.

Alle Informationen zu dem Produkt finden Sie auch auf unserer Homepage.

/ssu

Serie Cloud Security: Sind shared-images sicher?

Im Juni haben Darmstädter Forscher veröffentlicht, dass rund 30% von den 1100 untersuchten Images kritische Informationen beinhalten.

Dies haben Forscher aus Frankreich tiefgehender untersucht und dabei festgestellt, dass mehr als die Hälfte ihrer Untersuchungsgegenstände Informationen preisgaben, die besser vor Image-Freigabe hätten entfernt werden sollen.

Warum Image-Sharing?

Das Prinzip des Image-Sharings ist dafür gedacht, dass Entwickler für andere Entwickler bereits vorbereitete Systemumgebungen breitstellen (MI = Machine Image). Aber natürlich kann man es auch als Template verwenden. So kann mit relativ wenig zeitlichem Aufwand eine virtuelle Maschine gestartet werden (ohne Installation des Betriebssystems).

Was ist nun das Problem?

Untersucht wurden die auf allen Kontinenten frei verfügbaren AMIs (Amazon MIs). Dabei wurden diese auf Folgende Aspekte hin untersucht:

• sensible Restinformationen (private Schlüssel,Zugangsdaten in Konfigurationsdateien, Backup-Dateien oder der Command-History)
• Schwachstellen durch veraltete Software
• Installierte Backdoors und andere Malware
• Gelöschte Daten wiederherstellen

Gibt es eine Lösung?

Es gibt keine standardisierte Lösung. Sicherheit basiert auf Vertrauen. Offenbar vertrauen viele der Image-Ersteller auf den gutmütigen Nutzer und umgekehrt der Nutzer darauf, dass der  Image-Ersteller keine bösen Absichten hat, wenn Images erstellt oder zur Verfügung gestellt werden und diese durch Andere genutzt werden. Für den Fall dass ein Nutzer dem Image nicht vertraut, dann wird er es auch nicht verwenden und sich dann (hoffentlich) die Mühe machen ein eigenes Image zu erstellen.

Wenn jetzt ein Image-Ersteller sein Image unbedingt anderen Nutzern (es muss ja nicht öffentlich sein, es kann ja auch nur unter bestimmten Nutzergruppen geteilt werden) zur Verfügung stellen will, sollte unbedingt beachten, dass keine sensiblen Restinformationen wie zum Beispiel:

• Zertifikate oder Schlüssel
• Backupdateien
• Befehle (Command-History)
• Passworte wechseln (oder ganz entfernen) bzw. im Deployment-Prozess auf Zufallspasswörter zurückgreifen

hinterlassen werden. Die gelöschten Dateien sollten zudem sicher gelöscht bzw. überschrieben werden.

Viele Anbieter (hier als Beispiel Amazon) geben darüber hinaus auch Tipps zur Image-Erstellung und vorheriger Vorbereitung.

/sb

P.s.: Anlass gab der heutige Artikel bei Heise