Die normale Audio-Eingangsquelle für BBB ist das Mikrofon, um aber Videomaterial mit Ton adäquat über das Konferenzsystem abspielen zu können, muss man externe Software bemühen.
In unseren Fall Loopback, dass das Audio-Signal von beliebigen Programmen über ein virtuelles Gerät (“Loopback Audio”) weiterleitet. Einschränkung bei der Trial-Version: nach 20 Minuten wird ein White-Noise-Effekt über den Originalton geblendet, Preis für die Vollversion: 118 US-Dollar. Wenn man ein bisschen Zeit mit diesem kleinen nützlichen Tool verbracht hat, kann man die notwendigen Schritte in ein paar Augenblicken erledigen. Wichtig zu begreifen: Loopback funktioniert nur im Zusammenspiel mit der Systemsteuerung “Ton”.
Dort werden die Einstellungen für Ton-Ein (und -Ausgabe) festgelegt, dann erscheint auch die gewünschte Quelle zum Beispiel in BBB, Skype oder anderen Videokonferenzsystemen (auch Browser-basierten).
Wenn das Routing korrekt ist, wird auch der BBB-Echotest gestartet, der nur aktiv sein kann, wenn es eine Audio-Quelle gibt. Andererseits wird mit dem Hinweis abgebrochen, dass kein Mikro aktiv ist (z.B. bei einem Mac mini).
Ein Umschalten der Audio-Quelle während einer laufenden Konferenz ist nicht möglich, man muss sich aus- und wieder einloggen. Eine alternative Variante für diesen Fall wäre externe Audio-Technik (Mikrofon, Mischer usw.), die dann über Loopback als Quelle verwaltet wird.
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).
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"
#!/bin/sh
echo "Disk: "
read input_variable
echo "Search Sizes larger than x MB: "
read input_variable3
find "/volumes/$input_variable/" -type f -size +"$input_variable3"M -exec ls -lh {} \; 2> /dev/null | awk '{ print $5 " > " $NF}' #thatsit
exit
Update: die awk-Option “$NF” zeigt das letzte Feld des separierten Satzes an, zerschneidet dadurch aber Pfade mit Lehrzeichen. Die Option “$0” zeigt den kompletten Satz an, also auch den kompletten Pfad. Oder “$9 ” ” $10″, also Felder 9 und 10, das wäre der erste Teil des Pfades und der zweite Teil des Pfades inklusive einem künstlichen Lehrzeichen. Kann man noch weiter verfeinern, wichtig wäre aber Feld 9, den ohne den ersten Teil des Pfades hat man weniger Hinweise, wo man suchen würde …
