Der Eine oder Andere  von euch kann vielleicht schon erahnen, um welches Tool es hier geht. Ja natürlich … ich stelle euch heute mal “PSExec” vor. PSExec ist Bestandteil der PSTools, welche jedem von uns als die Sysinternals-Befehlszeilenprogramme bekannt sein dürften. Mit ihnen kann ein Kommandozeilen-Befehl an ein entferntes System abgesetzt und ausgeführt werden. Der Vorteil von PSExec ist, dass auf dem entfernten System kein Agent installiert oder sonstige clientseitige Vorbereitung getroffen werden muss. Wir können es auch sehr gut mit einen stark vereinfachten Telnet vergleichen.

Anwendungsbeispiele:

• Remote Ausführung des Befehls “wuauclt /reportnow” oder “wuauclt /detectnow” beim Patchmanagement
• Ausführung von Batchfiles und VB-Scripten z.B. zur Anpassung der Registry
• Ausführung von NTBackup von Remote mit einer Batch auf mehreren Systemen
• Einmalige Rollouts von Anwendungen (Internet Explorer, Inventarisierungs oder Antivirus-Agenten)
• etc.

Syntax:

psexec [\\Computer[,Computer2[,...] | @Datei][-u Benutzer [-p Kennwort]][-n s][-l][-s|-e][-x][-i [Sitzung]][-c [-f|-v]][-w Verzeichnis][-d][-<Priorität>][-a n,n,... ] cmd [Argumente]

Beispiel:

psexec \\computer ipconfig

Dieser Befehl dient der Ausführung von ipconfig, wobei die Ausgabe auf dem lokalen System erfolgt.

Argumente für PSExec:

Computer: Angabe des gewünschten Systems

@Datei: Verweist auf Textdatei mit den gewünschten Systemen

-a: Benennung der Prozessoren zur Ausführung der Anwendung

-c: Kopiert das angegebene Programm zur Ausführung auf das Remotesystem

-d: Beendigung von Anwendung nicht abwarten

-e: Lädt nicht das Profil des angegebenen Kontos

-f: Überschreibt das angegebene Programm auf Remotesystem

-i: Programme werden so ausgeführt, dass sie mit dem Desktop auf dem Remotesystem interagieren

-l: Führt das Programm als Benutzer mit eingeschränkten Rechten aus

-n: Gibt  Timeout in Sekunden an

-u: Gibt optionalen Benutzernamen für die Anmeldung beim Remotecomputer an

-p: Gibt das Kennwort für den optionalen Benutzernamen an

-s: Führt den Remoteprozess im Systemkonto aus

-v: Kopiert die angegebene Datei, wenn sie eine höhere Versionsnummer besitzt

-w: Gibt das Arbeitsverzeichnis für den Prozess an

-x: Zeigt Benutzeroberfläche

-Priorität: Führt den Prozess in angegebener Priorität aus

Programm: Name des Programms

Argumente: Zu übergebende Argumente

Links:

http://download.sysinternals.com/Files/PsTools.zip

Sascha Giebelhausen

Update 13.02.2010, 09:15 Uhr MEZ:

Wie vermehrt über Twitter und diverse Security-Portale gemeldet wird, vermutet man derzeit, dass ein bereits auf den vielen betroffenen Systemen installiertes Rootkit die Ursache für den Blue Screen of Death (BSoD) ist. So soll die %System32%\drivers\atapi.sys so durch das Backdoor:W32/TDSS-Rootkit verändert wurden sein, dass dies zum BSoD führt.

Ein Update zum Thema hat auch Jerry Bryant auf seinem MSRC-Blog veröffentlicht.

Thomas Gronenwald

Link:
[Symantec] http://www.symantec.com/connect/blogs/tidserv-and-ms10-015

Wie heute Nacht bereits “getwittert” wurde, gibt es derzeit einige Probleme mit dem Microsoft Sicherheitsupdate “MS10-015″. Viele Benutzer berichten davon, dass nach dem einspielen der Sicherheitsaktualisierung ihr Windows XP nicht mehr startet – schuld daran soll der Blue Screen of Death (BSoD) sein.

Ob es sich tatsächlich um einen Fehler innerhalb der Aktualisierung handelt oder ob es ein Kompatibilitätsproblem mit einer anderen Softwarekomponente gibt, ist bislang unklar.

Laut einigen Berichten, treten die Probleme “scheinbar” nur in den USA auf. Bisher kann ich das so bestätigen. Weder in unserem Labor, noch in anderen Kundenumgebungen konnten wir dieses Problem bislang reproduzieren.

Wie sieht es bei euch aus?

Solange nicht klar ist was diesen Fehler verursacht, sollte proaktiv der Patch ersteinmal nicht ausgerollt bzw. abgelehnt werden.

Thomas Gronenwald

Links:
golem.de
heise.de
krebsonsecurity.com
blogs.technet.com
twitter.com
tecchannel.de

Frequently Asked Questions – das sollte man über Secunia CSI 4.0.1 wissen:

Welche Vorraussetzungen benötige ich für CSI 4.0.1:

• https://*.secunia.com muss den vertrauenswürdigen Seiten im Internet Explorer hinzugefügt werden
• Port 443/TCP (outbound)
• Mindestens eine Auflösung von 1024 x 768

Welche Betriebssysteme werden unterstüzt?

• Windows 2000 SP4
• Windows XP SP2
• Windows Vista
• Windows 7
• Windows Server 2003
• Windows Server 2008

Wie müssen die Clients konfiguriert werden?

Zusätzlich zur bestehenden WSUS-Konfiguration muss in der Gruppenrichtlinie in der das Verhalten der WSUS-Clients gesteuert wird, die  Richtlinie “Allow signed updates from an intranet Microsoft update service location” aktiviert werden – dies ist zwingend notwendig um Patches über den WSUS und CSI zu verteilen.

Was ist der Single Host Mode?

Der Single Host Mode ist speziell für User mit mobilen Geräten entwickelt wurden. Aufgrund der Tatsache, dass Notebooks in der Regel nicht direkt mit dem Netzwerk des Unternehmens verbunden sind, ist ein geplanter Scan nicht möglich. Der Single Host Mode ist in der Lage, sobald eine Internetverbindung besteht einen Abgleich der installierten Programme mit der Secunia-Datenbank vorzunehmen. Die Ergebnisse werden lokal gespeichert und sobald eine Verbindung zum Unternehmensnetzwerk hergestellt wird, werden die Informationen an den CSI-Manager gesendet. So sollen Administratoren auch ihre mobilen Geräte im Blick behalten können.

Um diese Option nutzen zu können, ist es erforderlich CSI mit lokalen Administratorberechtigungen und Parametern auf dem Notebook zu installieren.

csia.exe -i -L

Ebenso ist es möglich CSI über das Active Directory mittels Gruppenrichtlinien zu installieren.

Beispielscript:

Was steckt hinter dem Network Appliance mode?

Der Network Appliance Mode ist für Administratoren gedacht die mehr als ein Netzwerk / Standorte betreuen. Hierbei ist es möglich an jedem Standort einen abgesetzten CSI im “Network Appliance Mode” zu betreiben und zeitgesteuerte Scans auszuführen. Die Ergebnisse werden von den einzelnen “Network Appliances” dann zum eigentlichen CSI-Manager berichtet.

Installation:

csia.exe -A -i

Welchen Agent benötige ich?

• Port 443/TCP (outbound)
• Windows Update Agent 2.0 oder aktueller

Welche Ports und welche Dienste werden benötigt?

• Port 139/TCP und 445/TCP
• File sharing aktiviert auf Clients
• Easy/simple file sharing deaktiviert auf Clients
• Windows Update Agent 2.0 oder aktueller

Welche Windows-Dienste müssen gestartet sein?

• Workstation service
• Server service
• Remote Registry service
• COM+ services (COM+ System Application: Automatisch)

Welche Funktionalitäten brauche ich zusätzlich zum CSI 4.0?

• WSUS installer
• Visual C runtime
• Microsoft .NET runtime V2.0 SP2

Thomas Gronenwald

Erster Eindruck? – überraschend cooles Look and Feel!

Wie von Secunia in der letzten Woche angekündigt wurde jetzt die erste Beta (4.0.1) der CSI 4.0 (Corporate Software Inspector) veröffentlicht. Die Symbiose aus WSUS und CSI soll es ermöglichen über den WSUS-Server Third-Party-Software, wie beispielsweise “Mozilla Firefox” oder “Adobe Reader” zu aktualisieren.

Registrierung:

Nach erfolgreicher Registrierung auf der Secunia-Website erhält man den Downloadlink, Usernamen und Pincode für die Freischaltung der Software. Die Lizenz ist innerhalb der Beta-Version auf zehn Clients begrenzt – der Testzeitraum endet zum 15. März 2010. Ich habe es mir natürlich nicht nehmen lassen, das ganze am Wochenende mal zu testen.

Installation:

Die Installation auf einem Windows Server 2008 x64 mit Service Pack 2 und WSUS 3.0 (3.2.7600.226) verlief problemlos und überraschend schnell. Nach weniger als einer Minute, konnte bereits mit der Konfiguration begonnen werden. Wichtig lediglich, das Ausführen des Setups mit Administratorberechtigungen. Außerdem ist es notwendig das Service Pack1  für das Microsoft .NET Framework 2.0 (bereits in Server 2008 enthalten), sowie das Microsoft Visual C++ 2008 SP1 zu installieren. Sicherlich gibt es in der Beta noch ein paar Dinge zu verbessern, aber der Grundtenor geht definitiv in die richtige Richtung.

Im Anmeldefenster muss man nun die per E-Mail erhaltenen Anmeldedaten eingeben.

Nach einem initialen Scan erstellt CSI einen detaillierten Report und bietet weitere Informationen an (Security Advisories, Downloads usw.).

Mit Hilfe der enumerierten Schwachstellen ist es jetzt möglich, ein Updatepacket für die Verteilung mittels WSUS zu erstellen. Wie das ganze nun wirklich im Zusammenspiel mit WSUS funktioniert, erläutere ich im zweiten Teil.

Thomas Gronenwald

Viele Unternehmen haben die Zeichen der Zeit bereits erkannt und nutzen eine Patchmanagement-Lösung wie etwa “WSUS” (kostenlos!). Jedoch wird immer noch zu oft auf die Aktualisierung von Third-Party-Software im Unternehmen verzichtet. So sind beispielsweise in vielen Umgebungen veraltete Adobe Reader oder Flash Player im Einsatz deren Sicherheitslücken mindestens genauso kritisch zu bewerten sind wie Schwachstellen im eigentlichen Betriebssystem.

Genau hier setzt nun Secunia mit CSI 4.0 an. Derzeit testet der dänische Security-Serviceprovider mit einem kleinen, ausgewählten Kundenkreis die Beta-Version des CSI 4.0 (Corporate Software Inspector).  Zusätzlich zu den bereits aus älteren Versionen bekannten Features, (Third-Party Software auf bekannte Sicherheitslücken zu scannen) soll es in Zukunft möglich sein die Software in eine bestehende WSUS-Infrastruktur einzubinden. So soll eine Symbiose zwischen WSUS und CSI enstehen, mit der es möglich ist, auch über den WSUS-Server bestimte Third-Party-Software zu aktualisieren.

Laut Jakob Balle, IT Development Manager bei Secunia, soll ab Februar ein Test für jedermann möglich sein.

Mehr Informationen gibt es hier:

http://secunia.com/blog/71/

Thomas Gronenwald

“Patchmanagement? Warum? Wir hatten noch nie Probleme!”

Seit nun mehr einem Jahr infiziert Conficker nicht ausreichend abgesicherte Microsoft-Betriebssysteme. Auch wenn es in den Medien immer ruhiger wird um den Wurm, ist es doch teilweise sehr erschreckend, wie unsensibel einige Unternehmen und Konzerne mit diesem Thema umgehen.

So erreichen uns in regelmäßigen Abständen Anrufe von deutschen Unternehmen, die auch nach dem vor mehr als einem Jahr erschienenen Security Patch “MS08-67″ und aufgrund nicht ausreichender Präventivmaßnahmen infiziert wurden.

Rückblick:
Vor zwei Monaten sitze ich mit meinem geschätzten Kollegen bei einem Bestandskunden, wir reden darüber, worüber wir irgendwie viel zu oft reden: Patchmanagement, Sicherheitsmanagement, Anti-Virus, Backup, Anti-Spam usw. Der Kunde sagt glücklich wie stolz zugleich: “Patchmanagement? Warum? Wir hatten noch nie Probleme!” Kein rankommen für uns, Argumente sind hier fehl am Platz – wir trinken unseren Café zuende und verabschieden uns.

Zwei Monate später:
Handyklingeln. Gleicher Kunde am anderen Ende. Über die Freisprechanlage meines Wagens begrüße ich Ihn mit überschwänglicher Freundlichkeit (es war ein Montag). Ich vernehme ein Wimmern gefolgt von folgender Aussage: “Herr… wir haben einen Befall! Conficker…!” Drei Stunden später waren wir vor Ort. Der Kunde hat nicht übertrieben. Homogene Windows 98/2000/XP/2003 Umgebung . Eines aber haben sie alle gemeinsam: Kein Anti-Virus, kein Patchmanagement (geschweige denn MS08-67) oder Servicepacks.

Fazit:
Conficker existiert weiterhin und ist angriffslustig wie am ersten Tag – das Risiko für nicht ausreichend geschützte Infrastrukturen steigt faktisch von Tag zu Tag an! Es ist lediglich eine Frage der Zeit, bis ungepatchte, nicht durch einen aktuellen Virenscanner geschützte Systeme infiziert werden. Sei es über das Internet oder über Wechseldatenträger.

Eine wahre Begebenheit, satirisch und bewusst überspitzt dargestellt, von Thomas Gronenwald und Florian Thiessenhusen

Problem erkannt, Problem gebannt?

Es ist zumeist an der Tagesordnung, dass einige WSUS-Clients Probleme verursachen. Einmal sind es die Securitypatches die einfach nicht heruntergeladen werden wollen, das andere mal meldet sich das System einfach überhaupt nicht mehr beim WSUS-Server. Zumeist kann der Fehler jedoch von den IT-Verantwortlichen vor Ort selbst gelöst werden.

In der Regel helfen dann nach einer kurzen Durchsicht des Eventlogs und des WindowsUpdate.log folgende Kommandozeilenbefehle weiter:

• wuauclt.exe /detectnow
• wuauclt.exe / reportnow
• wuauclt.exe /resetauthorization
• wuauclt.exe / demoui
• wuauclt.exe / showsettingsdialog
• wuauclt.exe / showwu

Aber es gibt natürlich auch Ausnahmen. So auch in diesem Fehlerfall. Einige Systeme (Windows 2000 Server SP4) wollen partout keine Verbindung mit dem WSUS-Server aufbauen, geschweige davon Securitypatches herunterladen. Alle möglichen Befehle und Tools erzielen auch nicht das gewünschte Ergebnis – der Kunde greift zum Hörer…

…Nach kurzer Erläuterung des Problems und einer wiederholten Überprüfung der Logs wird dann schnell klar – McAfee verrichtet im Hintergrund, seine Arbeit mehr als gründlich. Innerhalb des Eventlogs werden dabei folgende Event IDs erzeugt:

• Source: ESENT
  • Event ID: 412, 427 und 418

…und auch das WindowsUpdate.log generiert folgenden Fehlercode:

• error code 0xC80001FE

Nach einer kurzen Recherche wird schnell klar, dass das Problem dadurch entsteht, weil McAfee AntiVirus im Hintergrund das Verzeichnis %Windir%\SoftwareDistribution überprüft und die Datei *.edb für den Scan-Vorgang gesperrt hat. So ist es dem Update-Agent nicht mehr möglich auf diese Datei zuzugreifen.

Um dies nun zu ändern gibt es zwei Methoden:

1. Ausnahmen definieren / McAfee AntiVirus
2. Umbenennen des SoftwareDistribution-Ordners

Methode 1:

Damit der Echtzeitschutz bzw. die geplanten Scans die vom WindowsUpdate-Client benötigten Dateien nicht überprüft und sperrt, gilt es folgende Ordner und Dateien auszuschließen:

• %windir%\SoftwareDistribution\Datastore
  • %windir%\SoftwareDistribution\Datastore\Logs
    • Edb*.log
    • Res1.log
    • Res2.log
    • Edb.chk
    • Tmp.edb

Diese Methode sollte bevorzugt eingesetzt werden. Generell ist darauf zu achten bestimmte Ausnahmen für Server zu definieren – nicht nur für Clients, sondern eigentlich für alle üblichen Serversysteme. Hier sollten die Hersteller-Guidelines und Best Practices herangezogen werden.

Methode 2:

Diese Vorgehensweise kann das Problem kurzfristig lösen, sollte jedoch wie oben schon beschrieben, nur temporär eingesetzt werden.

Hierzu ist es notwendig eine Batch-Datei mit folgendem Inhalt zu erstellen:

net stop wuauserv
cd %systemroot%
ren SoftwareDistribution SoftwareDistribution.old
net start wuauserv

Diese Batch benennt den SoftwareDistribution-Ordner einfach um und gewährleistet dadurch wieder den Zugriff durch den WSUS-Client.

Links:
http://support.microsoft.com/kb/958048

Thomas Gronenwald

Wer seine installierten Sicherheitspatches schnell und einfach auf der Kommandozeile auslesen möchte, kann dies recht einfach mit der Windows Management Instrumentation Commandline (WMIC) tun.

Der Befehl dafür sollte so aussehen:

HTML-Datei:
wmic qfe list full /format:htable >C:\Sicherheitspatches.htm

CSV-Datei:
wmic qfe list full /format:csv >C:\Sicherheitspatches.csv

Das ganze ist dann als *.csv hervoragend für eine weitere Verarbeitung geeignet.

Thomas Gronenwald

Immer wieder stoße ich auf einen kleinen Fehler der den WSUS-Server an der Synchronisation des Contents hindert. Hierbei schlägt der Download vom übergeordneten Upstream-Server / Microsoft Update fehl. Innerhalb des Eventlogs wird dabei ein Eintrag mit der Eventid 10032 “The server is failing to download some updates” generiert.

Hintergrund:
Der BITS-Dienst stoppt während des Downloads unerwartet und startet nicht neu. Eine konfiguration über die GUI funktioniert nur temporär – über die Kommandozeile läßt sich das Problem jedoch lösen.

Lösung:
Über die Kommandozeile den BITS-Dienst konfigurieren (1.) und danach den WSUS- (2.) und BITS-Dienst (3.) neustarten:

1.) sc config bits start= auto
2.) net stop bits && net start bits
3.) net stop wsusservice && net start wsusservice

Anschließend in der WSUS-Verwaltungskonsole eine erneute Synchronisierung starten.

Mit folgendem Befehl läßt sich die Konfiguration noch schnell prüfen und ein Eventlog-Eintrag generieren:

wsusutil checkhealth

Voila! Jetzt sollten keine Eventlog-Einträge mehr im Application log erscheinen.

Links:
http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=.NET%20Framework&ProdVer=2.0.50727&EvtID=10032&EvtSrc=Windows%20Server%20Update%20Services&LCID=1033

Thomas Gronenwald