Archive for the ‘Malware’ Category

Spectre und Meltdown schönes Powershell-Script welches auch den Zugriff und vor allem die Mächtigkeit von NtQuerySystemInformation verdeutlicht

10 Januar 2018

Microsoft hat für die geplagten Administratoren von Windowssystemen ein kleines Powershellscript herausgegeben. Damit werden einige Infos aus dem Prozessor, BIOS/UEFI und von Windows ermittelt und dargestellt. Damit lässt sich zum momentanen Zeitpunkt dann leicht nachvollziehen, ob ein Rechner noch Updates oder Änderungseinstellungen braucht.

Hier zunächst der Link zum Powershell-Script: https://gallery.technet.microsoft.com/scriptcenter/Speculation-Control-e36f0050. Hier noch die offizielle Beschreibung dazu von MS: https://support.microsoft.com/en-us/help/4073119/protect-against-speculative-execution-side-channel-vulnerabilities-in. Gleich noch der Link zur Powershell Gallery: https://www.powershellgallery.com/packages/SpeculationControl/1.0.3.

Wenn man Updates von einem Hardwarehersteller benötigt, ist auch diese Liste noch hilfreich: https://www.heise.de/newsticker/meldung/Meltdown-und-Spectre-Die-Sicherheitshinweise-und-Updates-von-Hardware-und-Software-Herstellern-3936141.html. Hier eine Liste mit Links von MS: https://support.microsoft.com/en-us/help/4073757/protect-your-windows-devices-against-spectre-meltdown.

Aber wo ich eigentlich drauf hinaus wollte, war diese nette PInvoke-Definition im Powershell-Skript:

    $NtQSIDefinition = @‘
    [DllImport("ntdll.dll")]
    public static extern int NtQuerySystemInformation(uint systemInformationClass, IntPtr systemInformation, uint systemInformationLength, IntPtr returnLength);
‚@
   
    $ntdll = Add-Type -MemberDefinition $NtQSIDefinition -Name ’ntdll‘ -Namespace ‚Win32‘ –PassThru

Um NtQuerySystemInformation sinnvoll anwenden zu können, braucht man noch etwas drumherum:

[System.IntPtr]$systemInformationPtr = [System.Runtime.InteropServices.Marshal]::AllocHGlobal(4)
[System.IntPtr]$returnLengthPtr = [System.Runtime.InteropServices.Marshal]::AllocHGlobal(4)
[System.UInt32]$systemInformationClass = 201
[System.UInt32]$systemInformationLength = 4

Nun kann man einen Aufruf wagen:

$retval = $ntdll::NtQuerySystemInformation($systemInformationClass, $systemInformationPtr, $systemInformationLength, $returnLengthPtr)

Ist $retval vom Wert 0 ist alles gut, bei 0xc0000003 oder 0xc0000002 ist $systemInformationClass nicht vorhanden. Alle anderen Werte stellen einen Fehler dar.

Nach dem Aufruf zeigt $systemInformationPtr auf einen Speicherbereich, welche die Daten vom System enthält. Diese Daten kann man z. b. so abfragen:

[System.UInt32]$flags = [System.UInt32][System.Runtime.InteropServices.Marshal]::ReadInt32($systemInformationPtr)

$flags enthält anschließend die ersten 4Bytes.

Hat man die Informationen, die einen interessieren, dann gibt man den Speicher wieder brav frei:

if ($systemInformationPtr -ne [System.IntPtr]::Zero) {
  [System.Runtime.InteropServices.Marshal]::FreeHGlobal($systemInformationPtr)
}
 
if ($returnLengthPtr -ne [System.IntPtr]::Zero) {
  [System.Runtime.InteropServices.Marshal]::FreeHGlobal($returnLengthPtr)
}

Die Freigabe sollte auch im Fehlerfall erfolgen, weshalb man ein try catch drumherum bauen sollte.

Jetzt stellt sich die Frage, wie kommt man an die gültigen SysteminformationClass-Werte und die zurückgegebenen Strukturen? Diese findet man zum Beispiel hier: http://www.exploit-monday.com/2013/06/undocumented-ntquerysysteminformation.html. Weitere Infos gibt es hier: http://www.geoffchappell.com/studies/windows/km/ntoskrnl/api/ex/
sysinfo/query.htm
.

Wer mehr mit der Geschichte spielen möchte, der nimmt Get-NtSystemInformation aus dem PowershellArsenal: https://github.com/mattifestation/PowerShellArsenal.

Ach wenn ich schon am verlinken bin, hier noch wie man damit PerformanceCounter abfragen kann: http://blog.whatsupduck.net/2010/05/querying-peak-commit-bytes-with.html. Oder wie man gelockte Filehandles in Erfahrung bringen kann: https://blogs.technet.microsoft.com/heyscriptingguy/2013/12/01/weekend-scripter-determine-process-that-locks-a-file/. Der Kernel weiß eben über alles Bescheid Smiley.

Wer sich für weitere Möglichkeiten von NtQuerySystemInformation interessiert, der sollte sich noch nach ZWAPI.H umschauen…

Werbeanzeigen

Falschmeldungen von Virenscannern

19 Dezember 2017

Übereifrige Virenscanner können schon mal eine harmlose Software als gefährlich einstufen. Wenn man sich absolut sicher ist, dass eine Software Opfer einer falschen Klassifikation wurde, dann kann man solche sogenannten False Positives dem entsprechenden Antivirensoftwarehersteller melden.

Hier ein Link zu einer Seite, wo sich jemand viel Mühe zum Thema gemacht hat und von allen aktuellen Anbietern Adressen und Vorgehensweisen zum Einsenden von Fehlalarmen dokumentiert hat: https://www.techsupportalert.com/content/how-report-malware-or-false-positives-multiple-antivirus-vendors.htm

Vorsicht mit dem Start-MPWDOScan Cmdlet bzw. dem Offline überprüfen bei Windows 10

29 Mai 2016

Wer mit seinem Powershell auf aktuellen Windows 10 Versionen herumspielt, der könnte über das neue Cmdlet Start-MPWDOScan stolpern. Ein etwas kryptischer Name. Es gibt bereits eines mit dem Namen Start-MpScan, welches den Windows Defender aufruft und einen Scanlauf startet.

Aber für was steht nun WDO? Ganz einfach für Windows Defender Offline. Also kurz, damit kann man den Windows Defender im Offlinemodus starten. Dazu wird die aktuelle Windows Sitzung heruntergefahren und der Rechner bootet den Windows Defender Offline Scanner. Der führt seinen Scanlauf durch und bootet anschließend wieder das vorhergehend aktive Windows.

Seit der Verison v1511 von Windows 10 gab es nur das Cmdlet aber bei den aktuellen Preview-Versionen, gibt es nun bei den Windows Einstellungen bei “Update und Sicherheit” unter “Windows Defender” die Option “Windows Defender Offline” wo man den Button “Offline überprüfen” anklicken kann.

Soweit so gut und sicher eine prima Sache.

Wenn da nicht wie immer die berühmten Nebenwirkungen wären. Zunächst macht es Sinn, bevor man Start-MPWDOScan aufruft mittels Update-MpSignature die aktuellen Virendefinitionen zu laden, denn der Offline-Scanner legt einfach los und kann kein Update durchführen!

Nach dem Aufruf von Start-MPWDOScan oder anklicken von “Offline prüfen” passiert zunächst einmal nichts. Erst nach ca. einer Minute erscheint auf einmal ein Hinweisfenster, dass nun alle Anwendungen geschlossen werden. Wenn man dies nicht weiß, ist dies ziemlich verwunderlich, weil man einen Befehl absetzt und keine Reaktion bekommt und dann unvermittelt doch. Man kann zwar das Hinweisfenster schließen aber ein Abbruch des Vorgangs ist nicht direkt möglich! Nicht gespeicherte Daten gehen unweigerlich verloren! Wer schnell ist, kann allerdings per Win+R oder per Eingabeaufforderung ein “Shutdown /a” absenden, damit wird der Vorgang zunächst abgebrochen.

Wer nach einem Abbruch mittels “Shutdown /a” später dann versucht den Vorgang kontrolliert nochmal neu zu starten, der kann nach Eingabe von Start-MpWDOScan lange warten, denn es passiert einfach nichts mehr. Erst ein Neustart des Rechners mittels “Restart-Computer” bzw. normalem Neustart führt zur Offline-Prüfung, d. h. nach dem Abbruch macht der Rechner zunächst auf beleidigt.

Nächstes Problem ist die Art des Scanlaufs. Normalerweise kann man mittels “Set-MpPreference –ScanParameters FullScan” festlegen, dass man einen vollständigen Scanlauf machen möchte. Der eingebaute Windows Defender Offline ignoriert diese Einstellung und führt immer nur eine Schnellprüfung durch.

Wenn der Scanlauf beendet ist, stellt sich die Frage, wie man weiß, dass nichts gefunden wurde. Man könnte die Windows Ereignisanzeige mittels

Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational"|select -First 10

bemühen aber dort stehen eher wenig Infos drin. Es wird lediglich vermerkt, wann ein Offlinescan von der Anwendung “%1” initiiert wurde. Dies wird angezeigt durch die Nachricht “%1 hat Windows Defender Offline heruntergeladen und konfiguriert und führt es beim nächsten Neustart aus.”, ID 2030. Danach gibt es noch die Meldung “In der Konfiguration von Windows Defender wurde eine Änderung erkannt. Falls dies unerwartet ist, überprüfen Sie die Einstellungen, da die Änderung möglicherweise von Schadsoftware verursacht wurde…”, ID 5007. Dabei wird noch ein Registrierungskey genannt: HKLM\SOFTWARE\Microsoft\Windows Defender\Scan\OfflineScanRun, der von 0x1 auf 0x0 gesetzt wurde. Wenn es stimmt.

Da wohl niemand am Bildschirm kleben bleibt, wenn der Scan läuft, der fragt sich, wie kann man feststellen, ob der Scan ohne Probleme verlief? Dazu findet man im Verzeichnis C:\Windows\Microsoft Antimalware\Support entsprechende Log-Dateien. Die Kurzfassung steht in MSSSWrapper.LOG. Der Name MSSS steht für Microsoft Standalone System Sweeper, dem früheren Namen des Windows Defender Offline.

Es gibt auch noch Dateien mit Namen MPDetection-Datum-Uhrzeit.LOG und MPLog-Datum-Uhrzeit.LOG, dort stehen auch noch Infos.

In beiden Dateien, MSSSWrapper.LOG und MPDetection*.LOG werden Virenfunde verzeichnet, indem auf “Number of threats from scan: x”, “Found Virus:” und “DETECTION Virs:” darauf hingewiesen wird.

Wer selber die Reaktion des Windows Defender Offline testen möchte, der schaltet einfach mittels “Set-MpPreference –DisableRealtimeScanning $true” den Realtimescan-Modus ab. Danach kann man Problemlos mittels “New-Eicar –Path C:\Windows” ein Test-Virus pflanzen, der dann vom anschließenden Offline Scanlauf erkannt werden sollte. New-Eicar bekommt man hier: https://github.com/obscuresec/PowerShell/blob/master/New-Eicar.

Bleibt noch am Ende die Frage, wie sicher die Offline Methode ist. Denn wenn ein System bereits infiziert ist, könnte eine Malware auch nach dem Start des Offline-Scanners aktiv sein. Leider gibt es keine verwertbaren Infos wie dieser Vorgang vonstatten geht, so dass man hier nur spekulieren kann. Scheinbar wird ein WinPE hochgefahren, aber es wird dabei scheinbar auf Dateien aus dem bestehenden System zurückgegriffen…

Wobei es aber auch klappen könnte, wenn man Confirm-SecureUEFIBoot mit $true bestätigt bekommt, dann könnte theoretisch geprüft werden, ob das System sauber ist. Aber ob das stattfindet?

Malware-Plage und jetzt auch noch Superfish

22 Februar 2015

Es wird immer schlimmer und keiner blickt mehr richtig durch. Das ganze TLS und Zertifikatsgedöns ist nicht nur kompliziert, sondern kann auch schön ausgehebelt werden. Aktuelles Beispiel Visual Search bzw. Visual Discovery von Superfish.

Nicht nur, dass es Leute gibt, die sich bewusst oder unbewusst irgendwelche schrottigen Onlinevergleichstools auf den Rechner laden und dadurch massiv ausspioniert werden bzw. tolle Werbeeinblendungen bekommen, nein jetzt werden auch noch Rechner ab Werk mit solchen Programmen ausgeliefert.

Heise Online meldet:

Ab sofort können sich Cyber-Gangs online gegenüber Besitzern von vielen Lenovo-Laptos mit einer beliebigen Identität ausweisen und gefährliche Man-in-the-Middle-Angriffe tätigen.
http://www.heise.de/newsticker/meldung/Lenovo-Laptops-Sicherheitsluecke-erreicht-kritisches-Stadium-2555934.html

Die Vorgehensweise, die Sache ausnutzen zu können ist dabei recht einfach. Robert Graham zeigt mit einfachsten Mitteln, wie es geht. http://blog.erratasec.com/2015/02/extracting-superfish-certificate.html. Er startet einfach die Malware und erzeugt mittels Procdump von Sysinternals einen Speicherdump des Prozesses. Danach holt er sich wiederum mittels Sysinternals-Tool Strings alle Strings aus dem Dump. Schwupps hat er den privaten Schlüssel des Zertifikats. Normalerweise müsste man nun das Passwort für den privaten Schlüssel brutforcen. Aber das kann dauern. Also geht er einfach her und verwendet eine Dictionary-Attacke. Doch zunächst ohne Erfolg. Dann denkt er sich, vielleicht ist das Passwort ja im Stringdump enthalten und schwupps hat er es: “komodia”.

Warum ist dies nun alles so gefährlich? Ein schöner einleitenden Artikel bringt wiederum Robert Graham: http://blog.erratasec.com/2015/02/some-notes-on-superfish.html. Die Quintessenz daraus ist, auch wenn man die Malware deinstalliert, dass Stammzertifikat bleibt immer noch auf dem Rechner und erlaubt später problemlos “Man in the middle”-Attacken.

Damit nicht alles graue Theorie bleibt, geht wiederum Robert Graham zum Beweis über und bastelt mittels Raspberry Pi ein plastisches Beispiel. Mittels eines Pi für 40€, einem WLAN-Modul für 15€, einer Speicherkarte für 5€ bastelt er einen Man in the Middle Proxy. dazu verwendet er SSLSplit und die Zertifikate und Passwörter von Superfish und kann nun problemlos seine verschlüsselte TLS-Kommunikation mitlesen. http://blog.erratasec.com/2015/02/exploiting-superfish-certificate.html. Natürlich muss es nicht ein Pi sein, sondern kann jede x-beliebige Maschine sein, es geht nur darum deutlich zu machen, dass so ein kleines Stück Hardware für solche Attacken nicht teuer sein muss.

Ach und aus Erfahrung kann ich sagen, dass Rechner, bei denen so eine Spionagesoftware mal nicht richtig funktioniert, massiv Probleme mit ihrer Internetverbindung haben und der unbedarfte Benutzer ständig komische Fehlermeldungen zwecks Proxy und so Gedöns an den Latz geknallt bekommt.

Hier noch ein paar Powershell-Befehle mittels derer man das Superfish-Zertifikat ermitteln kann:

dir cert:\ -Recurse| where {$_.Subject -match "Superfish"}

oder direkt per Fingerprint:

dir cert:\ -Recurse| where {$_.Thumbprint -eq "C864484869D41D2B0D32319C5A62F9315AAF2CBD"}

Wer braucht da noch nen Staatstrojaner, wenn die Computerhersteller bereits alles dafür tun, die Geräte mit Malware auszustatten. Interessant in diesem Zusammenhang ist noch dieses: http://blog.fefe.de/?ts=aa16d2ff. Der große Bruder lässt grüßen…

Übersicht mit Bildschirmmasken von Bots welche eine polizeiliche Beschlagnahmung des Rechners suggerieren und deren Entfernung

5 April 2012

http://www.bka-trojaner.de/