In den letzten Jahren ist im Betriebssystem von Microsoft echt viel passiert. Und trotzdem gibt es immernoch einen Uralt-„Hack“, den ich schon unter Windows 7 genutzt habe. Er ist so simpel wie damals, lässt sich genauso leicht ausführen und ermöglicht es, vom Login-Bildschirm aus beliebige Kommandozeilenbefehle mit System-Rechten auszuführen. Damit könnt ihr Passwörter bestehender Nutzer zurücksetzen, neue Nutzer erstellen, Dienste registrieren, quasi Kontrolle über das System erlangen. Schauen wir zuerst einmal, wie es funktioniert und später, wir ihr euch dagegen absichern könnt.

„Erleichterte Bedienung“ beim Übernehmen des Systems

Die Schwachstelle, die hier ausgenutzt wird, ist die Erleichterte Bedienung im Anmeldebildschirm von Windows. Seit Windows 7 gibt es dieses kleine Symbol hier, welches beim Klick eine Toolsammlung startet. So harmlos sie auch wirkt … und jetzt kommt’s … sie wird mit vollen Systemrechten gestartet! Nicht eingeschränkte Nutzerrechte, nicht Adminrechte, Systemrechte! Das ist natürlich super-kritisch bzw. in manchen Fällen super-praktisch und bis heute ausnutzbar.

Der Trick ist einfach: Windows startet beim Klick auf das Icon von „Erleichterte Bedienung“ das Programm
[C:/]Windows/System32/Utilman.exe mit Systemrechten. Wenn wir nun diese ausführbare Datei mit einer in Utilman.exe umbenannten Kopie von cmd.exe überschreiben, ist der Trick schon fertig vorbereitet!
Nun lässt sich Utilman.exe allerdings nicht ersetzen, während Windows läuft, daher müssen wir in eine Pre-Boot-Umgebung und das dort erledigen. Das geht nun via Windows Installationsmedium oder anderen beliebige Boot-Systeme.

Physischer Zugriff + 1 Boot-Medium + 1 Befehl = unbegrenzte Möglichkeiten

Nun müsst ihr nur an dem PC sitzen und braucht ein Boot-Medium der Windows Version – Boot-DVD oder USB-Stick. Bootet in die Windows Installation und startet dort die Kommandozeile mit Shift+F10.
Sucht euch nun in der CMD den Buchstaben eurer Systempartition, der wird womöglich nicht derselbe sein wie im Windows Normalzustand.
Nutzt beispielsweise die Befehle „echo list volume | diskpart“ oder „wmic logicaldisk get deviceid, volumename“ für eine Auflistung aller Partitionen, dann solltet ihr den Namen eurer Systempartition wiederfinden.

Anschließend geht ihr in das Verzeichnis /Windows/System32 eurer Systempartition und macht es wie in den folgenden Screenshots:
Verschiebt euch (nur als Backup) die originale Utilman.exe irgendwo hin und kopiert anschließend die cmd.exe mit dem neuen Namen Utilman.exe in dasselbe Verzeichnis. Nun ist eure Utilman.exe unter dem Schafspelz der Verborgenheit eigentlich eine cmd.exe.

Das war’s! … außer Windows Defender geht dazwischen

Nun gibt es noch eine kleine weitere Hürde, abhängig von eurem Betriebssystem und dessen Version. Denn fertig seid ihr jetzt erst mit Windows 7 und Windows 10 älter als Version 1809 (verfügbar seit spätestens März 2019). In Version 1809 hat Microsoft den Windows Defender verbessert und erkennt seitdem dieses Hintertürchen. In Windows würde euch der Defender nach dem Login (wenn ihr der Besitzer wärt) folgende Info bringen:

Nun lassen wir uns dadurch aber nicht die Suppe versalzen und setzen also in allen neueren Versionen noch einen Schritt drauf: Wir deaktivieren einfach Windows Defender und dann funktioniert der Hack wieder.

Win10 Version 1809+: Windows Defender deaktivieren

Es gibt zwei Wege, das zu bewerkstelligen: Entweder drei Befehle abtippen oder via regedit GUI händisch erledigen.

Zeig mal die Codezeilen

:: 1) Diese Befehle einfach in eurer schon offenen CMD ausführen
:: 2) Achtet beim folgenden Befehl auf den richtigen Buchstaben eurer Systempartition!
reg load HKLM\tmp C:\windows\system32\config\SOFTWARE
reg add "HKLM\tmp\Policies\Microsoft\Windows Defender" /v DisableAntiSpyware /t REG_DWORD /d 1 /f
reg unload HKLM\tmp
via

Alternativ: Händisch: Startet über die sowieso schon offene CMD regedit. Klick HKEY_USERS an, Datei -> Struktur laden… -> /Windows/System32/config/SOFTWARE laden -> darin Policies/Microsoft/Windows Defender suchen -> DWORD 32 „DisableAntiSpyware“ mit Wert 1 erstellen

Erleichterter Vollzugriff

Erledigt! Schließt das Setup, startet die Kiste neu und klickt im Login auf das „Erleichterte Bedienung“ Icon. Nun sollte sich eine CMD öffnen und eröffnet euch breite Möglichkeiten. Sollten sich die originalen „Erleichterte Bedienung“ Tools öffnen, ist beim Ersetzen der Utilman.exe etwas schiefgelaufen. Sollte gar nichts passieren, handelt es sich womöglich um ein Windows 10 neuer als Version 1809 und der Defender ist nicht erfolgreich deaktiviert und blockt die CMD-Ausführung. Ansonsten, wenn alles geklappt hat, sieht ihr dieses Resultat:

Nun könnt ihr mit net user [existierender Nutzer] [neues Passwort] das Passwort zurücksetzen oder mit folgenden Befehlen einen neuen administrativen Nutzer erstellen:

net user [Nutzername] [Passwort]
net localgroup "Administrators" [Nutzername] /add

Disclaimer

Ein paar Anmerkungen hinten dran: Die Anleitung dient natürlich einzig eurer Fortbildung und Information – verschafft euch damit nicht unerlaubten oder ungewollten Zugriff auf fremde Systeme. Ich spreche außerdem „fälschlicherweise“ die ganze Zeit von „Hacks“ – hierbei handelt es sich aber nicht unbedingt um einen Hack, aus zwei Gründen:
1) Diese Manipulation ist Microsoft schon seit jeher bekannt und wird aber aus Gründen hingenommen und nicht stärker verhindert. Googlt für mehr Infos.
2) Physischer Zugriff auf den Zielrechner zu haben ist quasi Schummeln 😉

Law #2: If a bad guy can alter the operating system on your computer, it’s not your computer anymore.
Law #3: If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore.

10 Immutable Laws of Security

google-software-reporter-tool-cleanup-disable-deactivate-banner
Quelle: https://unsplash.com/photos/Xm3SPoOvNXs

Googles Software Reporter Tool, kurz SwReporter, ist schon ein mysteriöses Stück Software. Es ist nicht so leicht, irgendwelche Infos über Sinn, Zweck und Funktionsweise des Programms herauszufinden. Was auch daran liegt, dass das Tool eine Erweiterung des Chrome Cleanup Tools (CCT) ist. Das ist wiederum bekannter. Ich fasse mal meine Recherche zusammen, darunter noch ein paar Links für Interessierte.

Was ist der Software Reporter?

Der Software Reporter als Bestandteil des Chrome Cleanup Tools (CCT) wird mit Chrome installiert, befindet sich in einem Chrome Unterordner, wird dort auch regelmäßig aktualisiert und seine Aktivität kann nicht beeinflust oder deaktiviert werden. Das Programm wird in regelmäßigen Abständen (angeblich wöchentlich) automatisch unsichtbar im Hintergrund ausgeführt und ist dann für einige Minuten (angeblich +- 15 Minuten) mit niedriger CPU-Auslastung (als normaler Hintergrundprozess) am Arbeiten.
Das Tool soll angeblich nur Teile des Systems durchsuchen, die mit Chrome zusammenhängen und dort sowohl nach inkompatibler Software als auch Schadware scannen. Gemeint sind auch schädliche Extensions, Suchanbieter, Downloads und mehr. Metadaten von Funden werden an Google geschickt.

Über das Chrome Cleanup Tool mit all seinen Sicherheits- und Scanfeatures könnt ihr hier mehr lesen:
winfuture.de, vice.com, @justinschuh Tweets, Unwanted Software Protection Abschnitt der Google Chrome Privacy Whitepaper, Vorstellungsblogbeitrag, Google Hilfe

Mit dem nötigen Grundwissen kann nun jeder selbst entscheiden, ob das Tool eine erwünschte oder unerwünschte Aufgabe erfüllt und ob das Beeinträchtigung-Nutzen-Verhältnis positiv ausfällt. Für alle, die den Software Reporter deaktivieren möchte, erläutere ich nun, wie das geht:

Wie deaktiviere ich den Software Reporter?

Grundlegend ist es recht einfach: Wir entziehen dem gesamten System, inklusive Chrome also, die Berechtigung, das Programm auszuführen, zu aktualisieren oder neu einzurichten.
Öffnet den Pfad, in dem der Software Reporter liegt: C:\Users\[Nutzername]\AppData\Local\Google\Chrome\User Data\SwReporter\
und löscht alle Unterordner (vermutlich zwei), die quasi nur Versionsnummern als Ordnernamen haben.

  1. Rechtsklick auf den Ordner SwReporter -> Eigenschaften
  2. Öffnet den Sicherheit Tab
  3. und klickt darin auf Erweitert.
  4. Prüft, dass ihr selbst der Besitzer des Ordners seid. Das sollte der Fall sein. Wenn nicht, setzt euren Nutzeraccount über „Ändern“ als Besitzer.
  5. Klickt auf Vererbung deaktivieren und wandelt mit der ersten Option im folgenden Popup diese in explizite Berechtigungen um.

Berechtigungseinschränkungen clever wählen!

So gut wie alle Quellen im Netz nutzen diese Strategie. ABER sie machen auch alle denselben Fehler, denn sie entziehen die Berechtigungen unnötigerweise zu restriktiv, löschen beispielsweise alle Berechtigungen komplett. Nun darf man aber selbst den Ordner nicht mehr betreten, sonst werden die Berechtigungen wieder gesetzt und Chrome kann den Software Reporter wieder aktivieren.
Wir achten aber darauf, dass wir selbst nicht komplett handlungsunfähig sind und den ehemaligen Problemherd im Auge behalten können.

  1. Wir wählen jeden der drei Nutzer in der Liste nacheinander aus und führen jeweils die folgenden Schritte aus:
  2. Bearbeiten klicken, um die Rechtebearbeitung zu öffnen
  3. und mit Klick auf „Erweiterte Berechtigungen anzeigen“ die erweiterten Optionen anzeigen.
  4. Nun übernehmt ihr die Einstellungen des folgenden Screenshots: Es werden die Schreibrechte auf Dateien, Ordner und Attribute entfernt, Lese- und Schreibberechtigungen der Berechtigungen und das Auflisten des Ordners weiterhin erlaubt. Da Chrome aber für die Verwaltung des Software Reporters keine Berechtigungen setzen kann, ist es hiermit machtlos.
    Der Vorteil: Dadurch, dass die Auflistung des Ordnerinhalts noch erlaubt ist, können wir den Ordner immernoch betreten.

Vertrauen ist gut, Kontrolle ist besser

Nun hat Chrome keine Schreibberechtigungen mehr auf diesen Ordner, Dateien ausführen kann es auch nicht mehr (da wir vorher das Tool aus dem Ordner gelöscht haben, ist es eh nicht mehr drin) und ist somit ausgesperrt. Der Vorteil: Wir selbst können noch in den Ordner gucken und somit überprüfen, dass Chrome hier tatsächlich keine Ordner oder Dateien mehr anlegt, das kann man ja hin und wieder mal prüfen. Hätten wir alle Berechtigungen komplett entfernt, könnten bzw. dürften wir den Ordner selbst nicht mehr betreten und wären somit blind in der Hoffnung, dass Chrome darin nichts mehr macht.

Ich habe außerdem die Erfahrung mit anderen Programmen gemacht, dass sie gerne Fehler schmeißen und nicht mehr funktionieren, wenn man ihnen einfach komplett alle Berechtigungen auf Programmdateien oder -Ordner wegnimmt, da der Code versucht darauf zuzugreifen und sie gar nicht mehr findet. Wenn man nur Ausführung und Schreibrechte entfernt, sind die Auswirkung auf die Funktionsweise meist nicht so erheblich und teilweise ist dann wirklich nur die unerwünschte Funktionalität deaktiviert.

marc-olivier-jodoin-0TB3AiOu2g4-unsplash

Kürzlich fragte mich Blogbesucher Sebastian nach Hilfe: Mittels Batch-Skript sollen innerhalb eines Ordners, in einer bestimmten Unterordnertiefe, bestimmte Ordner umbenannt werden. In dem Artikel des Kommentars hatte ich Hilfestellung gegeben, bestimmte Aktionen auf alle Unterordner eines Ordners auszuführen. Die Einschränkung, diese Aktionen nur auf ein bestimmten Level von Unterordnern auszuführen, gab es nicht. Schauen wir uns das mal an.

Auslesen von tiefen Ordnerstrukturen

Die Grundstruktur bleibt erstmal gleich: Mit for /d in ([order]\*) do () werden Befehle auf alle Unterordner eines Ordners ausgeführt. Mit dem zusätzlichen Parameter /r durchsuchen wir rekursiv tiefe Ordnerstrukturen und ignorieren sogar Dateien für mehr Performance.

batch-deep-recursion-folder-manipulation-tiefe-ordnerstrukturen-bearbeiten-ausgabe
Mit for /d /r tiefe Ordnerstrukturen durchlaufen und ausgeben

Der Befehl wird dann leicht umgebaut: for /d /r "[ordner]" %%i in (*) do ()
Dann noch etwas Ausgabe mit dazu und wir haben fast den tree Befehl nachgebaut 😉

@echo off
setlocal enableDelayedExpansion 

for /d /r "%cd%" %%i in (*) do (
	echo %%i
)
pause
endlocal

Erkennung der Tiefe des aktuellen Ordners

Jetzt brauchen wir eine Erkennung der Tiefe. Das hat mich etwas länger beschäftigt als gedacht.
An die Tiefe der Rekursion von for /d /r scheint man leider nicht zu kommen und mehrere nicht-rekursive for-Schleifen ineinanderschachteln ist zu unflexibel. Stattdessen war folgender späterer Gedanke attraktiv einfach: Die Backslashes im Ordnerpfad zählen und damit die Tiefe erkennen.
Etwas sehr simpel aber das einzige, das ich erfolgreich umsetzen konnte. Wer hier einen besseren Ansatz hat, gerne ein Kommentar hinterlassen.

Das Zählen von Zeichen in einem String ist in Batch leider kein Einzeiler, aber das Rad muss ja nicht neu erfunden werden. Hier hat schonmal jemand eine Funktion dafür geschrieben. Möglich wäre auch die Nutzung von Powershell mit dem [string].split() Befehl, jedoch ist die Nutzung von Powershell in Batch ein Fass, dass wir hier jetzt nicht öffnen.

Nun zählen wir für jeden Unterordner die Backslashes, subtrahieren die Anzahl der Backslashes des Ordners, in dem das Skript ausgeführt wird und erhalten damit die relative Tiefe zum Skriptordner.

@echo off
setlocal enableDelayedExpansion 

set startdir=%cd%

call :GetCharCount startLevel %startdir% \

for /d /r "%cd%" %%i in (*) do (
	echo %%i
	call :GetCharCount level %%i \
	echo absolute Tiefe: !level!
	set /a relLevel=!level!-!startLevel!
	echo relative Tiefe: !relLevel!
)
pause
endlocal

:GetCharCount
  set _S=%~2
  set /a %~1 = 0
  for /L %%i in (0,1,10000) do (
    if "!_S:~%%i,1!"=="" (set "_S=" & exit /b)
    if /i "!_S:~%%i,1!"=="%~3" set /a %~1 += 1
  )
  set "_S="
  exit /b
batch-deep-recursion-folder-manipulation-tiefe-ordnerstrukturen-bearbeiten-tiefe-ausgeben
Absolute und relative Tiefe zum Skriptordner errechnen und ausgeben.

Verarbeitung von Ordnern in Abhängigkeit von Bedingungen

So, nun kann die Logik in Abhängigkeit von der Tiefe und weiteren gewünschten Faktoren mit ifs verbaut werden.
Alle Ordner in der Tiefe X UND mit dem Ordnernamen Y sollen umbenannt werden? Ich habe das beispielhaft (mit viel debug output) mal umgesetzt:

@echo off
setlocal enableDelayedExpansion 

set startdir=%cd%
set renameFrom=BitteUmbenennen
set renameTo=NeuerOrdnername
call :GetCharCount startLevel %startdir% \

for /d /r "%cd%" %%i in (*) do (
	echo ----
	echo %%i
	call :GetCharCount curLevel %%i \
	set /a relLevel=!curLevel!-!startLevel!
	for %%J in (%%i) do set foldername=%%~nxJ
	echo absolute Tiefe: !curLevel!
	echo relative Tiefe: !relLevel!
	echo Ordnername: !foldername!
	if !relLevel!==3 if "!foldername!"=="!renameFrom!" (
		echo **** RENAME ****
		set oldPath=%%i
		set newPath=!oldPath:%renameFrom%=%renameTo%!
		echo !newPath!
		move !oldPath! !newPath!
		echo ****
	)
)
pause
endlocal

:GetCharCount
  set _S=%~2
  set /a %~1 = 0
  for /L %%i in (0,1,10000) do (
    if "!_S:~%%i,1!"=="" (set "_S=" & exit /b)
    if /i "!_S:~%%i,1!"=="%~3" set /a %~1 += 1
  )
  set "_S="
  exit /b
batch-deep-recursion-folder-manipulation-tiefe-ordnerstrukturen-bearbeiten-umbenennen
Tiefe Ordnerstrukturen werden durchsucht und (beispielhaft) abhängig von der Tiefe und dem Ordnernamen umbenannt

Das ist jetzt natürlich beliebig erweiterbar aber das Prinzip sollte klar werden. Mehrere Voraussetzungen können einfach durch aneinanderreihen von ifs geprüft werden, quasi eine Einzeiler-Verschachtelung. Den aktuellen Ordnernamen ziehen wir mittels for-Befehl raus. Den neuen Ordnernamen bauen wir dank Batch String Manipulation. Das wäre in Powershell vermutlich ein Fünfzeiler aber sowas sieht in Batch irgendwie immernoch „schön“ aus 😉

Finale Version mit mehr Funktionen

Ich habe es vielleicht etwas übertrieben aber ich finde es immernoch interessant und unterhaltsam, in Batch zu coden, auch wenn es super umständlich ist und mit jeder Programmiersprache vermutlich einfacher wäre. Die finale Version beinhaltet weitere Möglichkeiten:

  • Steuerung des Tools mittels Parameter statt fest in den Code eingetragene Variablen – somit ließe sich das Ganze auch in eine .exe verwandeln und flexibel einsetzen. Optionale Modi (siehe unten), Ordnertiefe, Ziel und beliebig viele Quellordner könnt ihr beim Aufruf mit übergeben. Wenn das Programm ohne Parameter gestartet wird, wird eine Hilfe zur Nutzung ausgegeben.
  • Die Angabe mehrerer Quellordnernamen, die in einem Zielordner vereint werden sollen – die Dateien aller dieser Ordner werden im Zielordner derselben Ebene gesammelt.
  • Test-Modus zum Ausprobieren der Einstellungen. Im Testmodus geschieht alles so wie im Normaldurchlauf, nur dass die tatsächliche Datenverarbeitung übersprungen wird. Eine Ausgabe, wo sonst eine Dateiaktion passiert wäre, gibt es trotzdem.
  • Verbose- und Silent-Modus für viel oder wenig Ausgaben während der Abarbeitung. Im Silent-Modus gibt es nur 1 Ausgabe je Ordner, der umbenannt wird. Im Verbose Modus habt ihr viel zu Scrollen! 😉

Der Quelltext hier hier einsehbar: Code anzeigen

@ECHO off
SETlocal enableDelayedExpansion 

REM Author: Hannes Schurig
REM Date: 02.09.2019
REM More: https://it-stack.de/05/08/2019/tiefe-ordnerstrukturen-untersuchen-und-verarbeiten-mit-batch-2019

SET startdir=%cd%

IF "%1"=="" (
	ECHO ## USAGE ##
	ECHO.
	ECHO thistool.bat [--test] [--verbose] [depth] [renameTo] [renameFrom]
	ECHO test [optional]: Use "--test" to run in test mode. Normal outputs but no rename will actually be triggered.
	ECHO verbose [optional]: Use "--verbose" to get lots of output, without this there will be just one output per rename done.
	ECHO depth: In which folder level [relative to this tool] will rename do its work?
	ECHO renameTo: Folder name to rename to.
	ECHO renameFrom: As many folder names as you want that will get renamed. Foldernames with spaces in double quotes.
	ECHO.
	ECHO ## Exemplary ##
	ECHO.
	ECHO thistool.bar --test 3 newName "old Name 1" oldName2
	ECHO would run this tool in test-mode [no renames will be done] and both folders "old Name 1" [without quotes]
	ECHO and oldName2 in folder level 3 below this tools folder will trigger the rename process.
	ECHO thistool.bat --verbose 4 "new folder" "old Name" anotherFolder
	ECHO This will actually rename anotherFolder and "old Name" to "new folder" [both without quotes] in 4-level-deep subfolders 
	ECHO and output lots of stuff.
	PAUSE
	ENDLOCAL
	EXIT /B
)

:OptionalParams
REM number detection from: https://stackoverflow.com/a/17585404
ECHO(%~1|findstr "^[-][1-9][0-9]*$ ^[1-9][0-9]*$ ^0$">nul && GOTO :RequiredParams
IF "%1"=="--test" SET test=test&&SHIFT
IF "%1"=="--verbose" SET verbose=verbose&&SHIFT
GOTO :OptionalParams

:RequiredParams
SET depth=%1
SHIFT
SET renameTo=%1

SET "renameFrom=%*"
SET "renameFrom=!renameFrom:*%1 =!"
GOTO :LetsGo

:LetsGo
CALL :GetCharCount startLevel %startdir% \
IF "!verbose!"=="verbose" (
	ECHO ##############################
	ECHO verbose: !verbose!
	ECHO test: !test!
	ECHO depth: !depth!
	ECHO renameTo: !renameTo!
	ECHO renameFrom: %renameFrom%
	ECHO startdir: !startdir!
	ECHO level of startdir: !startlevel!
	ECHO ##############################
)

pause

FOR /d /r "%cd%" %%A IN (*) DO (
	CALL :GetCharCount curLevel "%%A" \
	SET /a relLevel=!curLevel!-!startLevel!
	FOR %%B IN ("%%A") DO SET "foldername=%%~nxB"
	IF "!verbose!"=="verbose" (
		ECHO ----
		ECHO %%A
		ECHO absolute Tiefe: !curLevel!
		ECHO relative Tiefe: !relLevel!
		ECHO Ordnername: !foldername!
	)
	IF !relLevel!==!depth! (
		FOR %%C IN (%renameFrom%) DO (
			SET tempRenameFrom=%%C
			SET cleanFolderName=!tempRenameFrom:"=!
			IF "!foldername!"=="!cleanFolderName!" (
				CALL :RenameFolder %%C "%%A"
			)
		)
	)
)

pause
endlocal
EXIT /B

:RenameFolder
	SET renameFromActual=%~1
	SET oldPath=%~2
	SET cleanRenameTo=!renameTo:"=!
	SET newPath=!oldPath:%renameFromActual%=%cleanRenameTo%!
	IF "!verbose!"=="verbose" (
		ECHO **** RENAME ****
		ECHO From: !oldPath!
		ECHO To: !newPath!
	) ELSE (
		ECHO *** Ordner !oldPath! wird umbenannt!
	)
	IF NOT "!test!"=="test" (
		IF NOT EXIST "!newPath!" (
			move "!oldPath!" "!newPath!">nul
		) ELSE (
			COPY /Y "!oldPath!" "!newPath!">nul
			RD /S /Q "!oldPath!">nul
		)
	) ELSE (
		ECHO Test-Modus aktiv, !oldPath! wird nicht umbenannt.
	)
	ECHO.
	EXIT /B

:GetCharCount
	SET _S=%~2
	SET /a %~1 = 0
	FOR /L %%i IN (0,1,10000) DO (
	IF "!_S:~%%i,1!"=="" (SET "_S=" & exit /b)
	IF /i "!_S:~%%i,1!"=="%~3" SET /a %~1 += 1
	)
	SET "_S="
	EXIT /B

Nutzung des Skripts

Das Skript wird über Paramter beim Aufruf gesteuert:

rename.bat [--test] [--verbose] [depth] [renameTo] [renameFrom]

### Was machen die Parameter? ###
--test: Startet den Testmodus des Tools. Es läuft normal durch, gibt normale Ausgaben aber der Umbenennungs-Befehl wird nicht ausgeführt. Gut zum Testen.
--verbose: Mit dem --verbose Parameter werden viele hilfreiche Ausgaben während der Ausführung gemacht. Ohne diesen Parameter gibt das Tool ausschließlich 1 Zeile pro erfolgter Umbenennung aus, nicht mehr.
depth: In welcher Ordnertiefe werden die Ordner geprüft und umbenannt?
renameTo: Neuer Ordnername
renameFrom: Beliebig viele alte Ordnernamen, die umbenannt werden sollen

### Beispielhafte Aufrufe ###
rename.bat --test 3 NeuerName AlterName1 "Alter Name 2"
rename.bat --test --verbose 4 "Neuer Ordner" "Alter Ordner" Testordner
usw.

@Sebastian: Ich hoffe, deine Anfrage ist damit erfolgreich beantwortet und du kannst den Code so für deine Zwecke einsetzen. Sag Bescheid, wenn du noch Hilfe brauchst.

Nachdem ich in den zwei vorhergehenden Artikeln über HSTS, X-XSS-Protection und die Content-Security-Policy geschrieben habe, folgen nun die letzten kleineren HTTP Security Header. Dazu zählen unter anderem X-Content-Type-Options, X-Frame-Options, Feature-Policy und Referrer-Policy. Auf der Webseite von OWASP, dem Open Web Application Security Project, findet ihr auch eine gute Übersicht aller Header, Einstellungsmöglichkeiten und Best Practices. Wie in den letzten Artikeln beschreibe ich die Umsetzung der Header mit Apache via .htaccess-Datei.

X-Content-Type-Options

Der Header ist recht simpel, denn er hat nur 1 mögliche Option: „nosniff“. Mit dieser Eigenschaft verhindert der Header, dass der Browser einen übermittelten Content-Type MIME type ändert. Stattdessen muss der MIME-Type in jedem Fall befolgt werden, was MIME sniffing Attacken (auch „content sniffing“ genannt) verhindern kann. Bei diesem Angriffsszenario werden Dateien mit einem falschen MIME-Type an den Browser geschickt, welcher diese dann anders als vorgesehen interpretiert:

Header always set X-Content-Type-Options "nosniff"

X-Frame-Options

Die Angabe eines X-Frame-Options Header gibt vor, ob andere Seiten deine Seite einbinden können – als frame, iframe oder object. Verhindert werden dadurch vor allem Clickjacking Attacken. Damit steht dies im Gegensatz zur CSP, welche die Einbindung anderer Seiten in deine Seite behandelt. Drei Optionen stehen zur Auswahl: DENY, SAMEORIGIN und ALLOW-FROM [Domain].
Für WordPress ist es empfehlenswert, die Option SAMEORIGIN zu wählen, da es sonst Problemen geben wird, beispielsweise beim Update von Plugins.

Header always set X-Frame-Options "SAMEORIGIN"

Feature-Policy

Die Feature-Policy ermöglicht die Kontrolle vieler Browser-APIs und somit die Einschränkung der Angriffsquellen bei vielen Funktionen. Für jede Direktive (= API) können folgende Optionen gesetzt werden: * (alle Quellen erlaubt), self, none, [Domains]. Die Funktionalität ist also der CSP sehr ähnlich, aber mit Fokus auf Features. Auch wenn die Browserunterstützung noch recht mau ist, empfehle ich die Nutzung: Beschränkt die einzelnen APIs so, wie sie in eurer Seite benötigt werden und schafft damit etwas mehr Sicherheit. Eine report-Direktive ist wohl schon in Arbeit, aber noch nicht implementiert, ich hoffe das kommt bald noch.

Mehr Informationen zu den Direktiven auf dieser Google-Seite, der Github Seite (manche davon ausführlicher erklärt) und aktiv gezeigt auf dieser Demo-Seite. Das reicht als Hilfe für das Setup.

Ich aktiviere bei mir die Features autoplay, fullscreen und picture-in-picture für ’self‘, allesamt für embedded Videos brauchbar, der rest wird mit ’none‘ deaktiviert:

Header always set Feature-Policy "accelerometer 'none'; ambient-light-sensor 'none'; autoplay 'self'; camera 'none'; encrypted-media 'none'; fullscreen 'self'; geolocation 'self'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; payment 'none'; picture-in-picture 'self'; speaker 'none'; usb 'none'; vr 'none'"

Ihr findet diese und weitere Einstellungen auch in den Webseiten-Einstellungen, die für jede Webseite angepasst werden können. Eure lokalen Settings stehen dabei noch vor den von der Seite vorgegebenen Featureeinstellungen:

mehr-website-sicherheit-mit-http-header-3-feature-policy-website-settings
Chrome’s Webseiten-Einstellungen für die Steuerung der Features

Referrer-Policy

Zuletzt noch die Referrer-Policy: Dieser Security Header steuert die Referrer-Information, die beim Aufruf eines Links auf eurer Seite mitgeschickt wird. Der Referrer ist dabei praktisch die Quelle der eingehenden Anfrage:

Grundsätzlich ist der Referrer eine nützliche Information, vor allem für Webseitenbetreiber und ihre Analysewerkzeuge wie Google Analytics. Sie erfahren, wie die Besucher auf die Webseite gekommen sind, von wo, eventuell mit welchen Suchbegriffen, und können ihre Seite mit diesen Informationen verbessern. Ich selber möchte hier also möglichst wenig restriktiv sein, aber dennoch die Sicherheit ein wenig erhöhen. Problematisch können Referrer-Informationen werden, wenn sie zu einer bösen oder unsicheren Seite weitergeleitet werden. Welche Möglichkeiten gibt es also?

Mögliche Optionen für die Referrer-Policy: no-referrer, no-referrer-when-downgrade, origin, origin-when-cross-origin, same-origin, strict-origin, strict-origin-when-cross-origin, unsafe-url

Ich möchte jetzt hier nicht auf jeden Punkt eingehen, das wäre unnötig. Informiert euch gerne bei Mozilla (mitsamt Beispielen) oder in diesem Blog zu den Auswirkungen jeder Eigenschaft auf den Referrer.

Ich benutze aus oben genannten Gründen nur die Option ‚no-referrer-when-downgrade. Diese ist möglichst locker beim Aufruf beliebiger http://-Links und schickt den gesamten Referrer da mit. Ich habe in meinem Blog keine kritischen Informationen, die nicht weitergeschickt werden sollten. Allerdings wird die Weiterleitung meines Referrers auf unsichere http://-Seiten verhindert, das erhöht die Sicherheit ein wenig. Überdenkt eure Seite, eure Links und wie ihr mit dem Referrer selbst umgehen wollt.

Achtung WordPress-Nutzer: Ich glaube seit WordPress 4.7 werden target=“_blank“ Links automatisch mit der Eigenschaft rel=“noreferrer noopener“ erstellt. Das mag gute Hintergrundgedanken haben, wenngleich auch die Seite informiert, dass noopener den Angriff verhindert und noreferrer nur als compatibility backup benutzt wird.
Also unabhängig vom Referrer-Policy-Setting würden Links keinen Referrer mitsenden.
Es gibt mindestens 2 verschiedene Codes für die functions.php, mit der sich das deaktivieren lässt, beispielsweise siehe Link in diesem Absatz. Das Problem hierbei: Beide Codes funktionieren nicht mit dem neuen Gutenberg-Editor. Ich habe hier bisher keinen Weg gefunden, das automatische noreferrer zu entfernen und daher bleibt dieser Security Header bei mir mehr oder minder Placebo und für alle Fälle.

Fazit

Das waren nun also die wichtigsten sieben HTTP Security Header in drei Artikeln, das war doch eine ganze Menge neues Wissen. Ich hoffe, dass ihr etwas Hilfe finden und eure Webseitensicherheit ebenfalls verbessern konntet. Es gibt noch weitere Security Header, diese waren dann aber entweder kaum verbreitet, kaum unterstützt oder kritisch diskutiert und mir daher zu edge case für meine Artikel.

Im Großen und Ganzen bin ich zufrieden, auch wenn man sicher immer noch besser und sicherer sein kann, hier mein securityheaders.com Ergebnis:

mehr-website-sicherheit-mit-http-header-3-securityheader-summary-final
SecurityHeaders.com Ergebnis A nach den Header-Optimierungen

Das Installieren von .NET-Framework 3.5 war unter Windows 7 noch relativ einfach – Online- oder Offline-Installer herunterladen und los! Unter Windows 10 kann das unter Umständen mehr Probleme machen. Die Fehlercodes 0x800F081F und 0x800F0906 können die Installation bzw. Aktivierung sehr umständlich machen. „Aktivierung“, da das .NET-Framework 3.5 bereits in der Feature-Liste von Windows 10 („Windows-Features aktivieren oder deaktivieren“ im Startmenü) gelistet wird und eigentlich nur per Häkchen aktiviert werden muss. Windows 10 lädt das dann über Windows Update nach. Im besten Fall. Oder beim Nachladen der Installationsdaten von Windows Update erscheinen die besagten Fehlermeldungen.

Die Installation erfolgt nun über ein Installationsmedium von Windows 10 – via USB oder ISO. Beides lässt sich binnen Sekunden über das Windows 10 Media Creation Tool herunterladen bzw. erstellen. Ich empfehle das ISO-Abbild, dieses lässt sich mit Rechtsklick -> Bereitstellen direkt in ein virtuelles Laufwerk verwandeln.

Nun braucht es für die Installation nur noch ein paar Befehle aus der administrativen CMD (als Admin starten!): 

del /q C:\Windows\SoftwareDistribution\Download
Dism /Online /Cleanup-Image /StartComponentCleanup
DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:D:\sources\sxs

Neustart, fertig!
via

Mit einem einfachen „Trick“ könnt ihr die wiederkehrende Tipparbeit in der Windows Kommandozeile vereinfachen: Aliase.
Gemeint sind selbst definierte (zumeist kurze oder einfache) Befehle, die andere (zumeist lange oder komplexe) Befehle ersetzen oder mehrere Befehle kombinieren.

Ein paar Beispiele, welche komplexeren Befehle durch einen einfachen Alias ersetzt werden könnten:

:ausführlichen IP-Config-Bericht in die Zwischenablage
ipconfig /all | clip
: Einfacher Netzwerkreset
ipconfig /flushdns && ipconfig /release && ipconfig /renew
: WLAN-Passwort von einem WLAN anzeigen
netsh wlan show profile [WLAN-Name] key=clear
: Git Branch aktualisieren, Pakete installieren, lokale Variable setzen und Node starten
git pull && npm i && set envtype=localtest && npm run debug

Aliase erstellen

windows-cmd-aliase-befehle-commands-path

Erstellt zuerst einen neuen Ordner, irgendwo auf eurem PC und kopiert euch den Pfad dorthin, z.B.: C:/aliase

Öffnet Erweiterten Systemeinstellungen (Start -> Erweiterte Systemeinstellungen oder Ausführen -> sysdm.cpl) -> Erweitert -> Umgebungsvariablen und fügt dort diesen Pfad im oberen und unteren Teil jeweils zu Path hinzu:

Dies bewirkt, dass alle Inhalte dieses Ordners jederzeit über die Kommandozeile aufgerufen werden können, also global aufrufbar sind.
Startet alle offenen CMD-Fenster danach neu, sonst kommt die Änderung nicht an.

Anschließend erstellt ihr euch in dem Ordner Dateien mit einem Dateinamen nach Format: [Befehl].bat – mit dem gewünschten Befehl/Alias. Beispielsweise: ipr.bat (Eselsbrücke „IP-Reset“)
Öffnet die Datei in einem Texteditor und fügt ein:

REM ipr.bat:
@echo off
echo Run: ipconfig /flushdns + /release + /renew
ipconfig /flushdns && ipconfig /release && ipconfig /renew

oder pir.bat („pull-install-restart“):

REM pir.bat:
@echo off
echo Run: git pull + npm i + npm run debug
git pull && npm i && npm run debug

REM und echo sind optional und dienen nur zur Info. Nachdem ihr die Datei gespeichert habt, lässt sie sich per Doppelklick starten und per CMD wie ein Befehl aufrufen:

Aliase mit Parametern

Ein weiterer Punkt kann noch wichtig sein: Wenn ihr dynamische Informationen (Parameter) an das Skript hinter dem Alias geben müsst. Beispielsweise braucht das Auslesen des WLAN-Schlüssels den WLAN-Namen (SSID) dafür oder der Ping brauch ein Pingziel.
Parameter lassen sich in Batch Skripte entweder per %1 … %9 (1. bis 9. Parameter) oder %* (alle angegebenen Parameter nacheinander) übergeben. Folgende Beispiele sind nicht besonders sinnvoll und sollen nur der Demonstration dienen:

REM rf.bat:
@echo off
echo unveil + delete %*
attrib -r -a -s -h %*&&del /f /q %*
REM p.bat:
@echo off
echo Usage: p [target] [count] [version]
echo ping %1 -n %2 -%3
ping %1 -n %2 -%3

Ein kleiner Aufwand für dich, aber eine große Erleichterung für deine Finger! 😉
Ich verwende Aliase, da ich als Programmierer im Alltag einige Befehle dutzende Male pro Tag ausführen muss.

Dieser Beitrag ist eine Fortsetzung der kleinen Artikelserie zur Optimierung der HTTP-Header für mehr Sicherheit auf der Webseite und für alle Webseitenbesucher. In Teil 1 ging es um die zwei noch recht einfachen Header HSTS und X-XSS-Protection. Teil 2 wird nun den recht komplexen aber mächtigen Header Content-Security-Policy behandeln.
Es benötigt vom Webmaster schon einiges an Vorbereitung und Testing, um mit diesem Header nicht auch Schaden anzurichten, aber der Zugewinn an Schutz gegenüber Angriffen oder Code Injection ist bemerkenswert.

CSP für umfangreiche Datenherkunftseinschränkung

Der Content-Security-Policy Header überprüft die Art und Herkunft von Daten und Anfragen während des Ladens und kann darauf reagieren. So können beispielsweise bestimmte Datentypen wie Skripte oder Stylesheets, die von einer anderen URL als der gerade zu ladenden Webseite angefragt werden, geblockt werden. Damit wird verhindert, dass unerwünschte, fremde oder gefährliche Inhalte geladen und ausgeführt werden. Das ist für gewöhnlich das Ziel von XSS-Angriffen, welche über zahlreiche Tricks versuchen, schädliche Inhalte in vertrauenswürdige Seiten einzubinden.
Damit das jedoch so funktioniert, muss der Webmaster für alle oder einzelne Inhaltstypen die jeweiligen vertrauenswürdigen Quellen definieren. Hier wird es knifflig. Vergisst der Admin eine vertrauenswürdige Quelle, werden Inhalte von dort nicht mehr geladen und fehlen auf der Webseite. Das kann dazu führen, dass Schriftarten oder Bilder fehlen, Skripte und somit ganze Funktionen nicht mehr laufen und die Webseite sich in andere Seiten nicht mehr einbetten lässt. 
Die vertrauenswürdigen Ursprünge sind entweder bekannt oder müssen erarbeitet werden.

1. Informieren

Eine zu restriktiv gesetzte CSP kann die Webseite wie gesagt teilweise beschädigen. Ich empfehle daher die mehrstufige Vorgehensweise: Informieren, testen, optimieren und schlussendlich aktivieren.

Ein erster Blick lohnt beispielsweise bei MDN. Hier sehen wir, welche Direktiven und welche Werte möglich sind. Ich gehe später nochmal genauer auf die einzelnen Werte ein. Erst einmal solltet ihr euch einen groben Überblick holen. Nutzt für weitere Informationen neben diesem Artikel auch die Intros von html5rocks.com, SelfHTML, den Mehrstufen-Ansatz von dareboost.com und die dort verlinkten weiteren Artikel zu CSP-Basics und auch die vielen kleineren Webseiten und Blogger mit deren CSP-Empfehlungen.

2. Testen

Wir beginnen mit Tests, die keine Schäden anrichten können. Dazu nutzen wir das Report-Only Feature der CSP. Hierfür wird eine valide CSP über Content-Security-Policy-Report-Only gesetzt, angewendet aber nicht ausgeführt. Es werden Warnungen und Fehler ausgegeben, aber keine Anfragen tatsächlich blockiert. Gesetzt wird es wie gehabt in der .htaccess der Webseite:

<IfModule mod_headers.c> 
  Header always set Content-Security-Policy-Report-Only: "default-src 'self'; img-src 'self' https://secure.gravatar.com https://s.w.org https://wordpress.org https://ps.w.org data:; font-src 'self' fonts.gstatic.com data:; object-src 'none'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; connect-src 'self'; child-src 'self'; report-uri https://report-uri.de/report.php;"
</IfModule>

Der Inhalt dieser CSP ist erst einmal nur kopiert von kittpress.com und angepasst an das Report-Only Feature via .htaccess. Von hier arbeite ich mich dann weiter.

Die CSP wird nun theoretisch angewendet, aber nicht endgültig ausgeführt. Nun könnt ihr anhand der Browser-eigenen Dev-Tools und der Reports die Problemstellen identifizieren.
Wie ihr eine Report-Schnittstelle einrichtet, die beispielsweise Reports in eine Logdatei schreibt, habe ich im ersten Teil dieser Artikelserie erklärt. Ihr könnt auch genau dieselbe Reportschnittstelle hierfür nutzen, das funktioniert einwandfrei. Alternativ könnt ihr auch externe Report Services wie diesen als Ziel für eure Reports wählen.
Gegenüber euren Browsertools haben die Reports den Vorteil, dass jede CSP-Verletzung jedes Website-Besuchers an euch gemeldet wird – ohne, dass ihr dafür dann noch etwas tun müsst. Außerdem habt ihr alle Meldungen dann in einer großen und zentralen Server-Log (ggf. auch per Mail) und müsst nicht selbst rumsurfen und die Devtools abkopieren. Es geht ansonsten aber auch ohne report-uri.

3.1 Optimieren

Bei meinem ersten Test landeten weit über 100 Reports innerhalb von 1 Minute in der Report-Log – das reicht für eine erste Optimierung. Also habe ich die CSP erst einmal wieder deaktiviert/auskommentiert und die ersten Ausnahmen erstellt. Dazu habe ich mir jeden Report einzeln angesehen, wenn nötig eine Ausnahme erstellt, alle Logeinträge dieses spezifischen Problems entfernt, nächten Report angesehen. So lange, bis die Report-Log wieder leer war.
Anschließend die neue CSP wieder einkommentieren und wieder dreistellige Reports sammeln.
Diesmal dauert es länger und es kommen kleinere oder speziellere Probleme zum Vorschein: Von externen Seiten eingebundene Bilder oder Medien, alte http:// embeds von z.B. alten Google Maps Projekten, extern genutzte Services, Einbindungen von Inhalten noch über meine alte Domain hannes-schurig.de, externe Inhalte in Kommentaren usw.
Ich habe hier durchaus 2-3 Stunden verbracht, alte Blogartikel zu bearbeiten, Links zu korrigieren, meine alte Domain überall zu ersetzen, Kommentare zu korrigieren und mehr.
Nach 4-5 Iterationen über 3 Tage ist meine CSP nun ganz gut und die letzten 24 Stunden ergaben nur noch Reports, die geblockt werden können. Es verbleiben Logs von geblockten Domains wie countmake.cool, loadsource.org und eluxer.net – fragt mich nicht, was das ist. Manche Blocks kommen durch data, blob oder chrome-extension, ich denke das ist auch okay zu ignorieren.

Mit dieser Endfassung bin ich nun also ganz zufrieden und werde diese nun endgültig aktivieren:

<IfModule mod_headers.c> 
  Header always set Content-Security-Policy-Report-Only: "default-src 'self'; \
script-src 'self' 'unsafe-inline' 'unsafe-eval' www.google-analytics.com https://*.googleapis.com https://www.google.com https://www.gstatic.com https://*.vgwort.de https://*.it-stack.de; \
img-src 'self' https://*.gravatar.com https://*.w.org https://*.wordpress.org www.google-analytics.com https://*.vgwort.de https://www.gstatic.com https://*.it-stack.de data:; \
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com https://*.it-stack.de https:; \
font-src 'self' data: https:; object-src 'none'; \
child-src 'self' https://www.google.com https://*.youtube.com https://*.it-stack.de https:; \
frame-src 'self' https://www.google.com https://*.youtube.com https://*.it-stack.de https:; \
worker-src 'self' https://www.google.com https://*.youtube.com https://*.it-stack.de https; \
connect-src 'self' wss://it-stack.de www.google-analytics.com https://*.vgwort.de; \
report-uri https://report.tld/report.php"
</IfModule>

Die Backslashes am Ende der Zeilen ermöglichen Zeilenumbrüche in .htaccess Dateien zur besseren Lesbarkeit.

3.2 Verstehen

Ein paar kleinere Hinweise oder Ergänzungen dazu:

default-src ’self‘ wird angewendet, wenn eine andere Direktive, die für eine Anfrage gebraucht wird, gar nicht vergeben wurde. Ist eine Direktive gesetzt, wird default-src komplett überschrieben, dortige Werte werden nicht vererbt. Beispiel: img-src abc.com würde das ’self‘ von default-src nicht vererben, ’self‘ sollte daher fast immer mit angegeben sein.

Mir ist klar, dass unsafe-inline/-eval die größte Schwachstelle der CSP sind, allerdings auch das größte Problem bei WordPress Blogs mit etlichen Plugins, Google Analytics und mehr. Der Aufwand, diese zwei Attribute zu entfernen, kann sehr aufwändig und langwierig werden. Ich betrachte diese CSP jetzt vorerst als (wenn auch schon fortgeschrittenes) MVP – minimum viable product 😉

CSS-Stylesheets wirken eher harmlos, enthalten schließlich nur kosmetische Informationen, wieso einschränken? Es ist nicht zu unterschätzen, wieviel Spionage auch durch CSS-Angriffe wie z.B. „CSS Exfil“ möglich ist.

Ebenso Fonts, ist das nicht etwas too much? Nein, auch Fonts können zu Keyloggern umfunktioniert und müssen daher ebenso gut eingeschränkt werden.

child-src ist noch CSP Version 2 und wird angeblich (laut dieses Validators) in Version 3 durch frame-src und worker-src ersetzt. Ich habe also vorsichtshalber einfach mal alle drei Direktiven so gesetzt. Parallel am besten immer noch mit Google’s Validator testen.

4. Aktivieren

Nachdem die CSP nun definiert und einige Stunden ohne neue benötigte Regel im Testbetrieb lief, kann sie nun aktiviert werden. Dazu einfach nur Content-Security-Policy-Report-Only in Content-Security-Policy umschreiben und fertig. Beobachtet selber noch einmal die Webseite, auch das Admin Backend und wenn alles funktioniert, ist es geschafft!

Ich werde vorerst die Log noch im Blick behalten, bin aber erstmal froh, auch diesen Punkt soweit erledigt zu haben:

Es wird langsam… 3 Security Header gesetzt, CSP ist neu