Check Point Remote Access Client Auto Deployment

Setting up a client-to-site VPN using the Check Point (CP) Remote Access Client is a common scenario in CP infrastructures. As the central gateway is set up the Remote Access Client is started, connected to the gateway using valid user credentials, the gateway fingerprint needs to be verified and accepted on the first connection attempt and the VPN is ready to be used as nearly everything
may be configured centrally.
But what if a deployment of thousands of clients is planned? What if the Remote Access Client will be used in an ATM scenario and the deployment has to work without user interaction? Accepting the fingerprint automatically or let the user accept it is not a good choice from a security perspective.
A working solution for this challenge is to deploy the fingerprint together with the Remote Access Client. As the fingerprints are stored in the registry this is possible within a few steps.
But at first a little warning:
The registry key containing the gateway fingerprint is not deleted while the Remote Access Client is uninstalled. When testing auto installation software multiple times on the same system the fingerprint has to be deleted manually before running a test. Otherwise the fingerprint verification is skipped and the test results may be incorrect.
The registry key containing the fingerprints is:
HKEY_LOCAL_MACHINE\SOFTWARE\CheckPoint\accepted_cn\
Check Point Preinstall client-to-site VPNs

Registry Fingerprint


You may now export all fingerprints or a single fingerprint at your choice using the ordinary regedit context menu. The German word “Exportieren” at the figure means “export”.
Checkpoint Remote Client Auto Deployment

Registry Export


As a result you will get a .reg file that you may import on all systems that should know the fingerprint.
To sum all that up to a one click installation a simple two line batch script is sufficient to import the fingerprint and start the “E80.42 for ATM” installation.

regedit /S Fingerprint.reg
CP_EPS_E80.42_RAC_Windows_ATM.msi /quit /forcerestart

This works for most auto deployments and avoids the necessity to verify the fingerprint on every new installation of the Remote Access Client.
Note: This has been tested using Check Point Remote Access Client E40.42 for ATM

How to Scan for System File Manipulations with Yara (Part 2/2)

How to Scan for System File Manipulations with Yara (Part 2/2)

As a follow up on my first article about inverse matching yara rules I would like to add a tutorial on how to scan for system file manipulations using Yara and Powershell. The idea of inverse matching is that we do not scan for something malicious that we already know but for anomalies within the system files. Chad Tilbury from Crowdstrike related to this method in his article describing a way to scan for this type of anomaly using their incident collection tool CrowdResponse. In my first article I described how we utilize this method in our incident response tool and promised a free solution based on available system tools.
The yara rules used to apply this method require the name of the observed file. Yara allows the file name to be passed via an external variable like in the following listing.

yara32.exe -d filename=iexplore.exe inverse-matching.yar iexplore.exe

But we have to define and pass this “filename” variable for every file we analyse while walking the directory tree.
So – what do we do?
First – we need a powershell script that walks a directory tree and feeds each file with an “.exe” extension together with the rule set and the file name as external variable to a yara32.exe. You could copy the script and paste it directly to the command line but I would recommend the following:
Prepare a folder with the following content:

  1. The powershell script as listed below – name it “inverse-scan.ps1”
  2. The ruleset listed below as “inverse-matching.yar”
  3. A version of Yara for Windows
  4. A batch script that invokes the powershell script with some parameters named “runit.bat”

The final result looks like this:

Yara Scan on Anomalies

Inverse Yara Matching Script Set


You can copy that folder to the target system, take it with you on a USB drive or provide a network share with its contents.
inverse-scan.ps1

Get-ChildItem -Recurse -filter *.exe C:\Windows 2> $null |
ForEach-Object { Write-Host -foregroundcolor "green" "Scanning"$_.FullName $_.Name; ./yara32.exe -d filename=$_.Name inverse-matching.yar $_.FullName 2> $null }

runit.bat

@ECHO OFF
powershell -ExecutionPolicy ByPass -File ./inverse-scan.ps1

inverse-matching.yar

rule iexplore_ANOMALY {
    meta:
        author = "Florian Roth"
        description = "Abnormal iexplore.exe - typical strings not found in file"
        date = "23/04/2014"
        score = 55
    strings:
        $upd_magic = { 44 43 }
        $win2003_win7_u1 = "IEXPLORE.EXE" wide nocase
        $win2003_win7_u2 = "Internet Explorer" wide fullword
        $win2003_win7_u3 = "translation" wide fullword nocase
        $win2003_win7_u4 = "varfileinfo" wide fullword nocase
    condition:
        not ( $upd_magic at 0 ) and not 1 of ($win*) and filename matches /iexplore\.exe/is
}
rule svchost_ANOMALY {
    meta:
        author = "Florian Roth"
        description = "Abnormal svchost.exe - typical strings not found in file"
        date = "23/04/2014"
        score = 55
    strings:
        $upd_magic = { 44 43 }
        $win2003_win7_u1 = "svchost.exe" wide nocase
        $win2003_win7_u3 = "coinitializesecurityparam" wide fullword nocase
        $win2003_win7_u4 = "servicedllunloadonstop" wide fullword nocase
        $win2000 = "Generic Host Process for Win32 Services" wide fullword
        $win2012 = "Host Process for Windows Services" wide fullword
    condition:
        filename matches /svchost\.exe/is and not 1 of ($win*) and not ( $upd_magic at 0 )
}
rule explorer_ANOMALY {
    meta:
        author = "Florian Roth"
        description = "Abnormal explorer.exe - typical strings not found in file"
        date = "27/05/2014"
        score = 55
    strings:
        $upd_magic = { 44 43 }
        $s1 = "EXPLORER.EXE" wide fullword
        $s2 = "Windows Explorer" wide fullword
    condition:
        filename matches /explorer\.exe/is and not 1 of ($s*) and not ( $upd_magic at 0 )
}
rule sethc_ANOMALY {
    meta:
        description = "Sethc.exe has been replaced - Indicates Remote Access Hack RDP"
        author = "F. Roth"
        reference = "http://www.emc.com/collateral/white-papers/h12756-wp-shell-crew.pdf"
        date = "2014/01/23"
        score = 70
    strings:
        $upd_magic = { 44 43 }
        $s1 = "stickykeys" fullword nocase
        $s2 = "stickykeys" wide nocase
        $s3 = "Control_RunDLL access.cpl" wide fullword
        $s4 = "SETHC.EXE" wide fullword
    condition:
        filename matches /sethc\.exe/ and not 1 of ($s*) and not ( $upd_magic at 0 )
}
rule Utilman_ANOMALY {
    meta:
        author = "Florian Roth"
        description = "Abnormal utilman.exe - typical strings not found in file"
        date = "01/06/2014"
        score = 55
    strings:
        $upd_magic = { 44 43 }
        $win7 = "utilman.exe" wide fullword
        $win2000 = "Start with Utility Manager" fullword wide
        $win2012 = "utilman2.exe" fullword wide
    condition:
        filename matches /utilman\.exe/is and not 1 of ($win*) and not ( $upd_magic at 0 )
}
rule osk_ANOMALY {
    meta:
        author = "Florian Roth"
        description = "Abnormal osk.exe (On Screen Keyboard) - typical strings not found in file"
        date = "01/06/2014"
        score = 55
    strings:
        $upd_magic = { 44 43 }
        $s1 = "Accessibility On-Screen Keyboard" wide fullword
        $s2 = "\\oskmenu" wide fullword
        $s3 = "&About On-Screen Keyboard..." wide fullword
        $s4 = "Software\\Microsoft\\Osk" wide
    condition:
        filename matches /osk\.exe/is and not 1 of ($s*) and not ( $upd_magic at 0 )
}
rule magnify_ANOMALY {
    meta:
        author = "Florian Roth"
        description = "Abnormal magnify.exe (Magnifier) - typical strings not found in file"
        date = "01/06/2014"
        score = 55
    strings:
        $upd_magic = { 44 43 }
        $win7 = "Microsoft Screen Magnifier" wide fullword
        $win2000 = "Microsoft Magnifier" wide fullword
        $winxp = "Software\\Microsoft\\Magnify" wide
    condition:
        filename matches /magnify\.exe/is and not 1 of ($win*) and not ( $upd_magic at 0 )
}
rule narrator_ANOMALY {
    meta:
        author = "Florian Roth"
        description = "Abnormal narrator.exe - typical strings not found in file"
        date = "01/06/2014"
        score = 55
    strings:
        $upd_magic = { 44 43 }
        $win7 = "Microsoft-Windows-Narrator" wide fullword
        $win2000 = "&About Narrator..." wide fullword
        $win2012 = "Screen Reader" wide fullword
        $winxp = "Software\\Microsoft\\Narrator"
        $winxp_en = "SOFTWARE\\Microsoft\\Speech\\Voices" wide
    condition:
        filename matches /narrator\.exe/is and not 1 of ($win*) and not ( $upd_magic at 0 )
}
rule notepad_ANOMALY {
    meta:
        author = "Florian Roth"
        description = "Abnormal notepad.exe - typical strings not found in file"
        date = "01/06/2014"
        score = 55
    strings:
        $upd_magic = { 44 43 }
        $win7 = "HELP_ENTRY_ID_NOTEPAD_HELP" wide fullword
        $win2000 = "Do you want to create a new file?" wide fullword
        $win2003 = "Do you want to save the changes?" wide
        $winxp = "Software\\Microsoft\\Notepad" wide
    condition:
        filename matches /notepad\.exe/is and not 1 of ($win*) and not ( $upd_magic at 0 )
}

Although the string descriptors list only some of the windows versions we’ve tested it against the following versions:
Windows 2000
Windows 2003 Server
Windows 7 (x64)
Windows 2008 R2
Windows 2012
What you get as result is a small anomaly scanner made completely with Windows tools and Yara. An administrator would just have to click the Batch file and run the script with admin rights. The following screenshot shows a scan on the Windows folder with a prepared malicious “iexplore.exe” in the subfolder “C:\Windows\AA_Testing”.

Yara Anomaly Scanner

Yara Inverse Matching Anomaly Scanner in Action


You could remove the section “Write-Host -foregroundcolor “green” “Scanning”$_.FullName $_.Name;” to show only the alerts or modify the script that it writes a log file.
We use all of these rules in our APT Scanner THOR and added further rules matching 3rd party tools attackers tend to replace or rename.
Inverse Yara Signature Matching (Part 1/2)

Inverse Yara Signature Matching (Part 1/2)

During our investigations we encountered situations in which attackers replaced valid system files with other system files to achieve persistence and establish a backdoor on the systems. The most frequently used method was the replacement of the “sethc.exe” with the valid command line “cmd.exe” to establish a backdoor right in logon screen by pressing shift several times, popping a command line running under LOCAL_SYSTEM rights.
It is obvious that none of our signatures matched on a valid Windows system file that just had a different name – cmd.exe renamed to sethc.exe. The signature was still intact, the MD5 and SHA1 hash of the file a well known one and listed in the “trusted-md5-hashesh” database. Therefore I introduced the so called “Inverse Yara Signature Matching” that checks if certain system files contain specific strings. THOR extends the Yara functionality by certain values that may be checked including the “filename” of the scanned file. This could also be accomplished by the Yara integrated functionality of external variables.
So – I combined the file name with strings that must exist in the system file and generated a rule that checks for the existence of 4 different strings that I extracted from all “sethc.exe” versions from the different operating system versions (Windows 2003, Windows XP, Windows 7, Windows 2008 and Windows 2012).

strings:
$s1 = "stickykeys" fullword nocase
$s2 = "stickykeys" wide nocase
$s3 = "Control_RunDLL access.cpl" wide
$s4 = "SETHC.EXE" wide
$filename = "filename: sethc.exe"
condition: $filename and not 1 of ($s*)

The rule matches if the analysed “sethc.exe” does NOT contain the typical string values and therefore indicates a manipulation. This method could be extended to other system files that are typically replaced or placed in uncommon directories like an “explorer.exe” in the “C:\Windows\System32” folder or a “svchost.exe” in the “C:\Windows” folder. We have already integrated checks that compares the file extension with the actual file type but this definitely bringst the anomaly detection to a new level.
Applying the rule listed above we detected over 15 server systems with this backdoor modification in place in a distributed THOR run. In case of the “sethc.exe” we had no false positives but they are possible if new operating system versions of the “sethc.exe” are checked.

Signature Matching sethc.exe

Yara Signature sethc.exe


With this method you are not able to determine the exact malware or malicious modification of the analysed file but you will at least be able to detect the modification.

Update 28.08.14

Thanks to Chad for the back reference to our blog. I even created more rules that match on valid Windows system files and described a way to scan a system with Windows PowerShell. You can find the second part of my article here.

Howto detect Ebury SSH Backdoor

Die folgende Yara Signatur kann für die Erkennung der Ebury SSH Backdoor verwendet werden.

rule Ebury_SSHD_Malware_Linux {
meta:
description = "Ebury Malware"
author = "Florian Roth"
hash = "4a332ea231df95ba813a5914660979a2"
strings:
$s0 = "keyctl_set_reqkey_keyring" fullword
$s1 = "recursive_session_key_scan" fullword
$s2 = "keyctl_session_to_parent" fullword
$s3 = "keyctl_assume_authority" fullword
$s4 = "keyctl_get_security_alloc" fullword
$s5 = "keyctl_instantiate_iov" fullword
$s6 = "keyutils_version_string" fullword
$s7 = "keyctl_join_session_keyring" fullword
$a1 = "%[^;];%d;%d;%x;"
condition:
all of them
}

Wer kein Yara verwenden möchte, kann auf diesen Workaround zurückgreifen.

find /lib -type f -size -50k -exec strings -f {} \; | grep '%\[^;\];%d;%d;%x;'

Weitere Informationen zur Erkennung von Ebury CERT Bund.

Signatur für Windows 0-day EPATHOBJ Exploit

Am gestrigen Tage wurde eine 0-day Schwachstelle am Microsoft Windows Betriebssystem bekannt, die für sich allein betrachtet bereits als schwerwiegend betrachtet wird, in Zusammenhang mit den uns bekannten Angreifer-Werkzeugen wie dem Windows Credential Editor allerdings als kritisch für jede größere Microsoft Windows Domänen-Infrastruktur angesehen werden muss.
Die im heise Artikel “Google-Forscher veröffentlicht Zero-Day-Exploit für Windows” erwähnte Schwachstelle ermöglicht es jedem Benutzer einer Windows Plattform, sich höchste Rechte auf dem System zu beschaffen. Durch Einsatz des Exploits kann sich selbst ein Gast Benutzer zu dem Benutzer “LOCAL_SYSTEM” eskalieren. Die Anwendung es Exploit ist simple und kann von Personen ohne Fachwissen durchgeführt werden.
Alle Windows Versionen und Architekturen sind betroffen.
Der Schadcode wird von kaum einem Virenscanner erkannt.
0day exploit EPATHOBJ

Ein einfacher Kommandozeilenaufruf erlaubt es, ein Program als LOCAL_SYSTEM zu starten


Folgende Szenarien sind durch das Exploit möglich:

  • Benutzer von Windows Client können sich lokale, administrative Rechte verschaffen
  • Benutzer auf Servern können sich dort administrative Rechte verschaffen
  • Benutzer auf Citrix Farmen können sich dort administrative Rechte verschaffen
  • Malware verwendet das Verfahren, um sich bei Ausführung im eingeschränkten Benutzerkontext lokale Systemrechte zu verschaffen und das System tiefgreifend zu verändern
  • Hacker (z.B. in APT Umfeldern) erhalten so auf Systemen das Recht, auf die gespeicherten LSA Sitzungen von Administratoren zuzugreifen (s.h. Windows Credential Editor Präsentation – Post-Exploitation)

Zusammenspiel mit Windows Credential Editor

Im Zusammenspiel mit dem “Windows Credential Editor” (WCE) wirkt diese Schwachstelle besonders verheerend. Mit dem Windows Credential Editor ist es möglich, LSA Sitzungstokens (NTML Hashes) und Klartextpassworte aus dem Speicher eines Systems zu dumpen. Diese Sitzungsinformationen bleiben teilweise Tage und Wochen im Speicher eines Systems zurück. Es reicht, dass der Angreifer Zugriff auf einen Mitgliedsserver erhält, um NTLM Hashes von Domänenadministratoren aus dem Speicher zu extrahieren.
Übliche Methoden zum Schutz vor diesen Attacken, wie die Wahl eines komplexen Passwortes, welches aus dem Hash nicht zurück berechnet werden kann, greifen nicht. Der WCE stellt Funktionen bereit, die einen einfachen Pass-the-Hash Angriff umsetzen. Dazu muss das Passwort nicht geknackt, sondern nur der Hash weitergereicht werden. In unserem Kundenumfeld setzen Angreifer diese Methode ein, um von Serversystemen in unbedeutenden Außenstandorten, Kommandozeilen mit Rechten eines Domänen-Administrators auf den Domänen-Controllern zu öffnen.
Diese Präsentation beschreibt die Funktionsweise des WCE im Detail.
Zur Ausführung des WCE sind allerdings administrative Rechte erforderlich, über die die Angreifer nicht immer verfügen. Mit dem neuen Windows Exploit erhalten sie diese aber einfach und schnell. Eine gesamte Windows Domäne fällt so in kürzester Zeit.

Gegenmaßnahmen

Wir haben auf Grund der Dinglichkeit eine Signatur für das von Tavis Ormandy veröffentlichte Windows Zero-Day-Exploit erzeugt. Andere Methoden zur Erkennung werden derzeit evaluiert. Wir werden Sie hier im Blog informieren, wenn wir andere Wege zur Erkennung (z.B. Windows Eventlogging) finden konnten.
Sie können ihre Systeme mit Hilfe von YARA manuell scannen.

rule Windows_0day_Exploit_1 {
meta: description = "Windows 0day EPATHOBJ local ring0 Exploit"
strings:
$a = "PATHRECORD" fullword
$b = "HRGN" fullword
$c = "FlattenPath" fullword
$d = "EndPath" fullword
$e = "PolyDraw" fullword
condition:
all of them
}

Nachdem Sie “yara-1.7-winXX.zip” heruntergeladen und entpackt haben, können sie über die Kommandozeile den Scan mit der oben angegeben Signatur starten.
Diese Signatur ist auch Teil unseres Incident Response Scanners THOR, zu dem Sie hier mehr Informationen finden können.
Einen Schutz auf kritischen Systemen bietet eine Lösung wie “AppSense Application Manager“, zu dem wir auch Support anbieten. Er setzt das “Trusted Ownership” Modell um, welches auf Windows Systemen sicherstellt, dass nur diejenigen Executables ausgeführt werden dürfen, die von einer vertrauenswürdigen Gruppe auf das System gebracht wurden (z.B. Administratoren). So können z.B. die Benutzer von Citrix Systemen weiterhin ihre dort abgelegten Anwendungen verwenden, aber keine eigenen, eingebrachten Executables zur Ausführung bringen.

Exploitcode

Der Exploitcode wurde von uns kompiliert und untersucht.
Eine von uns veranlasste Analyse des Exploitcodes durch Malwr.com finden Sie hier.
(die kompilierte Executable kann von dieser Seite heruntergeladen werden – wir übernehmen keine Haftung für Schäden, die durch die Ausführung entstehen)

Update

Wir konnten den bereitgestellten Code nur auf 32bit Betriebssystem Versionen zum Laufen bringen. Es steht jedoch außer Frage, dass die Schwachstelle nach Anpassungen auch auf 64bit Systemen ausnutzbar sein muss.
Interessant ist auch, das Tavis Ormandy den lauffähigen Exploitcode von einem chinesischen Studenten bereitgestellt bekommen hat.

Linux Sicherheit – Rootkits automatisch erkennen

Linux Sicherheit – Rootkits automatisch erkennen

Ein wichtiger Teil unserer Arbeit ist es, Risiken in IT-Systeme zu identifizieren, diese auszuschließen oder auf ein hinreichendes Niveau zu minimieren. Bei der Planung von Sicherheitsarchitekturen nimmt die Verwendung von automatisierten Malwarescannern schon lange einen elementaren Platz ein. Clientsysteme ohne Anti-Viren-Programm sind nahezu undenkbar. Ein anderes Bild zeigt sich jedoch, trotz eines erhöhen Schutzbedarfs, bei den Serversystemen. Entsprechende Lösungen sind verfügbar und sollten ein zwingender Baustein jedes Sicherheitskonzeptes sein.
Bei Rootkits, die darauf spezialisiert sind sich durch Manipulation des Betriebssystems der Entdeckung zu entziehen, stoßen viele der gängigen Lösungen an ihre Grenzen. Drei Möglichkeiten dieser Gefahr auf Linuxsystemen durch zusätzliche Sicherheitsmechanismen zu begegnen zeigt der folgende Artikel.
Eine mögliche Lösung bietet die Software AIDE (http://aide.sourceforge.net/). Mit AIDE können, wie das folgende Listing zeigt, Veränderungen im Dateisystem schnell sichtbar gemacht werden. Das Beispiel zeigt eine Manipulation der Ausführbaren Dateien des Systems um durch Veränderungen des Programms ps einen schadhaften Prozess zu verstecken.

#!/bin/bash
#Beispielkonfiguration um nur /bin zu überprüfen
aide -c sample_bin.conf -C
AIDE 0.15.1 found differences between database and filesystem!!
Start timestamp: 2012-10-12 14:21:40
Summary:
Total number of files: 118
Added files: 0
Removed files: 0
Changed files: 1
# Änderungsdetails gekürzt
changed: /bin/ps

Der Mehraufwand, der für den Einsatz von AIDE geleistet werden muss, besteht darin, nach Systemupdates die Datensätze der bekannten Dateien zu aktualisieren.
Doch auch diese Methode hat ihre Grenzen, wenn der Linux-Kernel manipuliert wurde oder Änderungen lediglich in Ordnern auftreten, die nicht überwacht werden. Hier kann eine andere Klasse von Tools zur Rootkiterkennung verwendet werden.
Die Software chkrootkit (http://www.chkrootkit.org/) prüft auf die Anwesenheit bekannter Rootkits. Dies entspricht etwa dem Vorgehen der signaturbasierten Virensuche.

#!/bin/bash
chkrootkit
ROOTDIR is `/'
Checking `amd'
... not found
Checking `basename'... not infected
Checking `biff'
... not found
...
Searching for sniffer's logs, it may take a while... nothing found
Searching for rootkit HiDrootkit'
s default files... nothing found
Searching for rootkit t0rn's default files... nothing found
Searching for t0rn'
s v8 defaults... nothing found
Searching for rootkit Lion's default files... nothing found
Searching for rootkit RSHA'
s default files... nothing found
...

Genau wie die signaturbasierte Virensuche muss für ein Programm wie Chkrootkit bekannt sein wie sich ein Rootkit verhält, bevor die Suche erfolgreich ist. Dies bedingt aktuelle Signaturen wie bei jedem Virenscanner auch.
Einen anderen Weg verfolgt das Programm Unhide (http://www.unhide-forensics.info/). Unhide versucht mit verschiedenen Methoden die Anwesenheit von versteckten Prozessen und Ports aufzudecken. Dies kann auf einen Rootkitbefall hindeuten.

#!/bin/bash
unhide -f procall brute
Unhide 20110113
http://www.unhide-forensics.info
[*]Searching for Hidden processes through /proc stat scanning
[*]Searching for Hidden processes through /proc chdir scanning
[*]Searching for Hidden processes through /proc opendir scanning
[*]Searching for Hidden thread through /proc/pid/task readdir scanning
[*]Starting scanning using brute force against PIDS with fork()
Found HIDDEN PID: 14496 " ... maybe a transitory process"
[*]Starting scanning using brute force against PIDS with pthread functions

Das Vorgehen von Unhide ist dabei übertragbar auf jedes Rootkit, dass einen Prozess versteckt. Birgt jedoch die Gefahr von False-Positives. Die gefundenen PIDs sollten daher weiter geprüft werden, bevor von einem Rootkitbefall ausgegangen werden kann.
Sollte sich der Verdacht auf einen Rootkitbefall erhärten ist es jedoch ratsam, dass betroffene System aus dem laufenden Betrieb zu nehmen und eingehend forensisch zu untersuchen.
Dies ist insbesondere bei Serversystemen sehr schmerzhaft. Der Befall mit einem Rootkit kann jedoch bedeuten, dass das System bereits vorher von einem Hacker übernommen wurde und das Rootkit als „versteckter Eingang“ installiert wurde. Dieser Gefahr sollte man sich nicht ungeprüft aussetzen.

Systeme mit RDP Schwachstelle MS12-020 im Netzwerk aufspüren

Systeme mit RDP Schwachstelle MS12-020 im Netzwerk aufspüren

In einem Artikel des Security Monitoring Blogs wird beschrieben, wie man mit Hilfe eines Nmap Skriptes die RDP Schwachstelle MS12-020 an Systemen mittels eines Netzwerkscans aufspüren kann.
Wir haben für einen unserer Kunden einen Paket des Nmap Scanners erzeugt, welches bereits das nötige Skript enthält und nur entpackt werden muss, um benutzt werden zu können. Einzig ein WinPcap muss ebenso auf dem System (mit Adminrechten) installiert werden, um das Nmap Scanner Skript anwenden zu können, da Pakete erzeugt werden müssen, die jeder Norm widersprechen. Das WinPcap Installationspaket liegt dem Paket bei und befindet sich im Hauptverzeichnis als “winpcap-nmap-4.12.exe”.
Die RDP Dienste unserer Testsysteme (Windows 7 und Windows 2003) blieben durch die Tests unberührt – d.h. stürzten nicht ab.
Das Nmap Paket der Version 5.61TEST5 mit dem Skript von Aleksandar Nikolic kann hier und aus unserer Download Sektion geladen werden.
Nach dem Download und dem Entpacken kann man nmap folgendermaßen ausführen und das lokale Netz scannen lassen. (Das Zielnetz muss entsprechend angepasst werden)

nmap.exe -sC -vv -p 3389 --script ms12-020-rev 10.1.1.0/24
Plesk Sicherheitsproblem mit Microupdates lösen

Plesk Sicherheitsproblem mit Microupdates lösen

Ein Sicherheitsproblem im Server-Management-Werkzeug Plesk bedroht viele über dieses System gemanagte Serversysteme. In einem heute veröffentlichten heise-Alert wird das Problem beschrieben und auch auf die Workarounds für ältere Systeme verlinkt. Die Lücke wird nach Angaben heises bereits aktiv ausgenutzt.
Alte Plesk Versionen können mit Hilfe des “Autoinstallers” für Micro-Updates mit dem Fix versorgt werden.
Konkret empfiehlt sich folgendes Vorgehen:
1. Plesk Home Directory finden bzw. Version feststellen

dpkg -l | grep plesk

bzw.

find / -name "autoinstaller*"

2. In das “sbin” Verzeichnis wechseln
z.B.

cd /opt/psa/admin/sbin/

3. dann folgenden Befehl ausführen

autoinstaller --select-product-id plesk --select-release-current --reinstall-patch --install-component base

Auf diese Weise können Sie Ihre Plesk Installation schnell fixen.