ssh-brute-force-attacken können einen Rechner nicht nur potenziell gefährden, sondern auch während der Attacke durch die erhöhte Prozessorlast in die Knie zwingen. Einige Versuche haben gezeigt, dass die Auslastung auf den attakierenden Geräten zwischen 50 und 70 Prozent in die Höhe schnellt und dann normale Anwendungen Probleme bekommen. Aber meist ist diese Art von Attacke auf die Schnelle nicht erkennbar.
#!/bin/bash while [ $loop 30 ] ; do process="sshd" if [ $(ps -ef | grep -v grep | grep $process | awk '{print $2}' | wc -l) -gt 10 ] then
afplay alert_01.wav
fi done
exit0
Mehr als Proof-of-Concept und nicht als reelle Abwehr (dafür sind normalerweise Firewalls nötig) ist dieses kleine Script gedacht. Es erkennt die steigende Auslastung durch die SSH-Daemons (sshd) und spielt wiederholend einen Ton ab (alert_01.wav), solange wie die Attacke existiert. Mehr praxistauglicher wäre dieses Script als ein entsprechender Daemon/Service, der permanent die sshds überwacht, optional.
Für Debian/Raspbian einfach “aplay” statt “afplay” verwenden.
Die Gründe, um ein macOS-Passwort legal cracken zu müssen, können vielfältig sein: Passwort vergessen (kommt vor!), Aufklärung von Straftaten (kommt ebenfalls vor), Todesfall (kommt früher oder später immer vor). Ganz unten stehen die Maßnahmen, um das Cracken der nachfolgenden Prozedur definitv zu unterbinden, aber zuerst orientieren wir uns an der macOS-Standard-Installation und diese bietet die notwendigen Angriffsflächen, um das Passwort wiederherzustellen (ohne es zu ändern). Diese Prozedur erfordert physischen Zugang zu dem Rechner.
Der erste Schritt ist, die DS-Datei des entsprechenden User-Accounts zu extraieren. DS (Directory Service) ist ein DB-basierter Dienst, der die lokalen Nutzer innerhalb macOS verwaltet. Diese Datei befindet sich in /private/var/db/dslocal/nodes/default/username.plist (siehe Bild 1).
Der enthaltende Ordner (Default) ist über SIP geschützt, dieses lässt sich über die Recovery Partition ein- und ausschalten.
Danach muss der Rechner in den Single-Modus versetzt und die dslocal-User-Datei auf einen externen Datenträger kopiert werden.
Aus dieser wird dann der Hash für das Cracking ausgelesen.
Hashcat unter macOS funktioniert nur mit bestimmten OpenCL-Libraries, die Mindestvorraussetzungen sind Rechner mit Nvidia- oder Intel-GPUs, Maschinen mit ATI-GPUs fallen hier schonmal raus, das betrifft aber nur die Mac Pros bis Baujahr 2012. Je neuer der Rechner, desto besser.
Hashcat benötigt eine Hash-Datei, um eine Attacke ausführen zu können, diese wird aus der DS-Datei generiert mithilfe von diesem Script. Dieses Script enthält fest-codierte Pfade um den Hash zu extraieren, die DS-Datei muss in /tmp/ liegen.
Danach das Python-Script mit Root-Rechten ausführen:
Jetzt muss etwas gebastelt werden, denn nur ein Teil dieses Shadow-Kennworts ist für Hashcat verwertbar, und zwar nur die ersten 128 Zeichen nach dem vierten $-Zeichen (mit TextWrangler lassen sich Zeichenkettenlängen in Echtzeit messen).
Der Nutzername (bob_sinclair) muss ebenfalls raus, die fertige Hash-Datei anhand von dem Beispiel oben sieht dann so aus:
Hashcat braucht den Hash (hash.txt) und eine Wörterbuch-Datei, mit der die Attacke ausgeführt wird. Im Beispiel wird die Ziel-Datei (cracked_hash.pot) in /tmp/ abgelegt.
In meinem Fall hat die erfolgreiche Attacke genau 12 Stunden gedauert, anhand einer Wordlist-Datei mit 14 Millionen Einträgen
(iMac, Intel Core i5, Intel HD Graphics 6000 1500 MB, macOS 10.13.6).
Prävention
Um diese Variante des Password-Crackings komplett zu unterbinden, genügt es FileVault einzuschalten. Oder ein Open-Firmware-Passwort einzurichten. Denn dann wird eine Passwort-Abfrage vor der Recovery-Partition notwendig und ohne den Zugriff auf die DS-Datei erübrigt sich der Rest.
Um eine frische CC-Installation anlegen zu können, müssen nicht nur die Applikationen deinstalliert sein, auch die umfangreichen Prefs, Caches und sonstige Dateireste müssen weg. Meist verhindern diese nicht gelöschten Adobe-Daten den Download über den CC-Manager komplett bzw. der Fortschritt stoppt nach einer gewissen Zeit. Natürlich ohne eigene Fehlermeldung.
Es gibt ein entsprechendes Script, was ich schon ein paar Mal erfolgreich angewendet habe:
Damit werden radikal ALLE lokalen Adobe-Daten gelöscht, die Orte, in denen das Script aktiv ist, sollte man sich mal in Ruhe anschauen. Interessant ist, das der Flash Player weiterhin unter der Marke Macromedia läuft (Macromedia wurde 2005 von Adobe gekauft).
Um ein Audio-File mit einem simplen Tastendruck abspielen zu können, braucht man eine Mindest-Konfiguration aus RaspberryPi und einem Audio-Ausgabe-Gerät, in meinem Fall ein Raspberry Pi Zero WH und ein Speaker pHat. Dazu natürlich noch ein Taster und ein Gehäuse, beides sehr robust, beides von Conrad Electronics.
Zum Einrichten habe ich einen RPi 3+ und einen externen Speaker benutzt, danach sollte alles auch dem RPi Zero laufen. Zur Software: ich habe das Raspbian-Buster-Lite-Image benutzt, also ebenfalls die Minimal-Variante. Optional ist die SMB-Installation, ist nur einfach angenehmer um die Audio-Daten leicht hin- und herzuschieben. Das Script sieht folgendermassen aus:
Wichtig die Kennung für den GPIO-Port, hier 17 (Pin: 11), und der Verweis auf die Audio-Datei plus optionaler Angabe des Audio-Devices (CARD=0). Bei integrierten, höherwertigen DACs ist diese Angabe empfehlenswert und notwendig, für den Standard-Klinken-Ausgang nicht. Auto-Starten des Scriptes: das passiert durch einen Eintrag in /etc/profile, meine Ergänzung lautet hier:
Absolut wichtig hier: das System muss auf Auto-Login eingestellt sein, deswegen über sudo raspi-config > Boot Options > Desktop/CLI > Console AutoLogin dort die entsprechende Einstellung machen.
Diese Variante einer mobilen Webcam enthält softwareseitig nur ein Skript für die Erstellung und FTP-Upload des “webcamimage.jpg” sowie einen Cron-Job der jede Minute ausgeführt wird.
An zusätzlicher Software wird sshpass benötigt, Datenübertragung erfolgt mit SFTP. Das normale FTP wird von kommerziellen Hosting-Firmen nicht mehr unterstützt.
Beispiel-Syntax für Download: user@host:directory/webcamimage.jpg
Beispiel-Syntax für Upload: user@host:directory/ <<< $'put webcamimage.jpg'
Hier das komplette Script (password muss in Quotationmarks):
#!/bin/bash
cd /home/pi/webcam/
sudo rm *.jpg
raspistill -rot 180 -w 1640 -h 1232 -o "webcamimage.jpg"
sleep 1
sshpass -p "password" sftp -oPort=22 user@host:directory/ <<< $'put webcamimage.jpg'
exit
Hardware ist hier ein Raspberry Pi Model B Plus Rev 1.2 plus Kamera Modul V2 plus TPLink TL-WN722n (Rev1, Atheros).
Ein TimeMachine-Backup zu haben ist schön, aber noch besser ist es, die exakte Notfall-Prozedur ebenfalls zu üben. Der Worst-Case wäre es, bei einem Ernstfall festzustellen, dass das TM-Backup nicht funktioniert. Die Gründe können auch da vielfältig sein, aber ein Szenario ist definitiv fehleranfällig: keine dezidierte Backup-Platte zu verwenden, sondern eine “gemischte Platte”, die den Backup-Ordner und andere Daten enthält. Diese neue Aufgabenstellung für diese Festplatte kann auch wieder neue Probleme generieren. In dieser Konstellation sollte unbedingt mal ein Test mit dem vorhandenen Backup durchgeführt werden.
Dazu im Recovery-Modus starten (Taste CMD und R beim Start gedrückt halten), danach im Recovery-Menü den ersten Punkt “Von TimeMachine-Backup wiederherstellen” auswählen. Dort würden zuerst die vorhanden TimeMachine-Orte aufgelistet werden (lokale Platten und/oder Netzwerk-Platten) und danach würde zweitens die TimeMachine-Zeit/Datum ausgewählt werden. Dass beides zusammen funktioniert ist NICHT zwingend, deswegen ist diese Prozedur so wesentlich. Falls also einer der Schritte nicht funktioniert: sofort ein neues Volume oder Festplatte für ein frisches Backup definieren und auch sofort durchführen.
Update: manche Probleme hinsichtlich eines (Netzwerk-) TimeMachine-Backups entstehen durch die nachträgliche Änderung des Computer-Namens, siehe auch diesen Artikel.
Ein QC-Projekt, dass als ScreenSaver die aktuellen News der Fakultät darstellt. Die Datei in ~/Library/ScreenSaver bewegen und im Kontrollfeld “Bildschirmschoner” auswählen. Funktioniert nur bis macOS 10.13 HighSierra.
Einen Desktop-Mac passiv (also ohne Tastatur, aber mit Monitor) zu betreiben kommt im Ausstellungskontext häufig vor. MacMinis, MacPros und iMacs, die mit vorgefertigten Programmen bestückt werden und nur noch eingeschaltet werden sollen. Das Problem dabei ist: der Bluetooth-Keyboard-Assistent startet bei nicht angeschlossenen Eingabe-Geräten automatisch (auch bei ausgeschalteten Bluetooth) und verhindert das nachfolgende Ausführen von Programmen, ScreenSaver etc.
Die Lösung ist, diesen Assistenten zu deaktivieren bzw. umzubenennen.
sudo mv "/System/Library/CoreServices/Bluetooth Setup Assistant.app" "/System/Library/CoreServices/Bluetooth Setup Assistant.dissabled.app"
Vorraussetzung dafür: SIP deaktivieren.
Um den Assistenten wieder einzuschalten kehrt man die Umbenennung um:
sudo mv "/System/Library/CoreServices/Bluetooth Setup Assistant.dissabled.app" "/System/Library/CoreServices/Bluetooth Setup Assistant.app"
