Keydnap über signierte Transmission-Anwendung verbreitet

Letzten Monat haben ESET-Forscher einen Artikel über die neue OS X Malware Keydnap verfasst. Diese ist in der Lage, Schlüsselbundinhalte von OS X zu stehlen und ein permanentes Backdoor aufzubauen. Während der Analysen war zunächst unklar, wie die Opfer durch OSX/Keydnap kompromittiert werden. Im Artikel aus dem letzten Monat hieß es, dass schädliche Anhänge in Spam-Mails, unsichere Webseiten oder etwas Anderes schuld sein könnten.

Letztendlich stellte sich heraus, dass OSX/Keydnap über eine vermeintlich sichere Webseite verbreitet wurde. Die Malware verteilte sich durch eine neu kompilierte Version der legitimen BitTorrent Client Anwendung Transmission.

Sofortige Reaktion vom Transmission-Team

Nur wenige Minuten nachdem ESET das Team von Transmission über die schädliche Datei informierte, verschwand sie von der Transmission-Webseite und von den Betreibern wurde eine Untersuchung eingeleitet, um herauszufinden, wie das passieren konnte. Offensichtlich wurde die Signatur am 28. August 2016 erstellt, aber das Bundle nur am nächsten Tag vertrieben. Alle, die Transmission v2.92 zwischen dem 28. und 29. August 2016 heruntergeladen haben, sollten ihr System auf Kompromittierungen testen und nach folgenden Verzeichnissen Ausschau halten:

/Applications/Transmission.app/Contents/Resources/License.rtf
/Volumes/Transmission/Transmission.app/Contents/Resources/License.rtf
$HOME/Library/Application Support/com.apple.iCloud.sync.daemon/icloudsyncd
$HOME/Library/Application Support/com.apple.iCloud.sync.daemon/process.id
$HOME/Library/LaunchAgents/com.apple.iCloud.sync.daemon.plist
/Library/Application Support/com.apple.iCloud.sync.daemon/
$HOME/Library/LaunchAgents/com.geticloud.icloud.photo.plist

Wenn eines der Verzeichnisse existieren sollte, wurde die Transmission-Anwendung ausgeführt und Keydnap agiert dann mit hoher Wahrscheinlichkeit auf dem System. Beachtung sollte man auch dem schädlichen Disk Image schenken, welches als Transmission2.92.dmg benannt ist. Das legitime lautet aber Transmission-2.92.dmg (Man beachte den Bindestrich).

Ähnlichkeit mit KeRanger

Wem diese Verfahrensweise womöglich bekannt vorkommt, liegt richtig. In März 2016, veröffentlichte Palo Alto Networks einen Blogpost der vor der ersten OS X Ransomware warnte. Tatsächlich nutzt Keydnap die gleiche Technik, um sich zu verbreiten.

In beiden Fällen wird ein Block von Schadcode zu den Hauptfunktionen von Transmission eingefügt. Der zusätzlich eingebaute Code, der für das Ablegen und Ausführen der Nutzlast verantwortlich ist, ähnelt sich erstaunlicherweise sehr.

Transmission Hauptfunktion OSX / KeRanger zu droppen

Transmission Hauptfunktion OSX / KeRanger zu droppen Fortsetzung

Wie im KeRanger-Fall wurde ein legitimer Codesignaturschlüssel zur Signierung des schädlichen Transmission-Bundles genutzt. Es unterscheidet sich zwar vom gültigem Transmission Zertifikat, aber es ist immer noch von Apple signiert und kann die Gatekeeper-Schutzfunktion umgehen.

# Malicious Transmission.app
$ codesign -dvvv /Volumes/Transmission/Transmission.app
Executable=/Volumes/Transmission/Transmission.app/Contents/MacOS/Transmission
Identifier=org.m0k.transmission
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=6304 flags=0x0(none) hashes=308+3 location=embedded
Hash type=sha1 size=20
CandidateCDHash sha1=37ffe70260919ee70e9f2a601d5ad00e2dd5a011
Hash choices=sha1
CDHash=37ffe70260919ee70e9f2a601d5ad00e2dd5a011
Signature size=4255
Authority=Developer ID Application: Shaderkin Igor (836QJ8VMCQ)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Signed Time=Aug 28, 2016, 12:09:55 PM
Info.plist entries=38
TeamIdentifier=836QJ8VMCQ
Sealed Resources version=2 rules=12 files=331
Internal requirements count=1 size=212

# Clean Transmission.app
$ codesign -dvvv /Volumes/Transmission/Transmission.app
Executable=/Volumes/Transmission/Transmission.app/Contents/MacOS/Transmission
Identifier=org.m0k.transmission
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=6304 flags=0x0(none) hashes=308+3 location=embedded
Hash type=sha1 size=20
CandidateCDHash sha1=a68d09161742573b09a17b8aef05f918a1cebcac
Hash choices=sha1
CDHash=a68d09161742573b09a17b8aef05f918a1cebcac
Signature size=8561
Authority=Developer ID Application: Digital Ignition LLC
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Mar 6, 2016, 3:01:41 PM
Info.plist entries=38
TeamIdentifier=5DPYRBHEAR
Sealed Resources version=2 rules=12 files=328
Internal requirements count=1 size=180

ESET hat auch Apple über die kompromittierte Codesignatur informiert.

Neben der Verbreitungsmethode verfügen Keydnap and KeRanger über eine weitere Ähnlichkeit im Code. Es geht dabei um die C&C URL Ressourcenpfade und Parameter.

KeRanger: /osx/ping?user_id=%s&uuid=%s&model=%s
Keydnap: /api/osx?bot_id=%s&action=ping&data=%s (Parameter wie POST Daten, verschlüsselt mit RC4)

Keydnap jetzt in Version 1.5

Während der Kommunikation mit dem C & C-Server, enthält Keydnap eine interne Version. Wir konnten die Version 1.5 in der Binary beobachten.

Es ist immer noch mit dem modifizierten UPX verpackt, wie wir bereits in unserem ersten Artikel über Keydnap beschrieben. Der Patch, den wir auf Github veröffentlichten, um die ausführbare Datei zu entpacken, funktioniert auch noch bei der neuen Variante.

Einen signifikanten Unterschied gibt es dann doch. Die neue Version enthält einen eigenständigen Tor-Client. Dieser ermöglicht Keydnap seine onion-gesteuerten C&C-Server ohne die Hilfe von Tor2Web zu erreichen.

Innerhalb Keydnap wird Curl dazu benutzt, um den lokalen Tor-Client als Proxy zu verwenden

Es gibt nur einen zusätzlichen Befehl, den wir im Vergleich zur vorherigen Version analysierten. Dieser neue Befehl, mit der ID 10 ermöglicht dem C & C-Server auf eine andere URL gelegt zu werden und diese auf der Festplatte abzuspeichern.

Der folgende RC4-Schlüssel wird verwendet, um HTTP POST Daten zu verschlüsseln und die Antwort zu entschlüsseln: “u-4&LpZ!6Kgu^=$a“.

Die eingebaute C&C-Server URL lautet jetzt: hxxp://t4f2cocitdpqa7tv.onion/api/osx

Keydnap Version 1.5

Wie man OSX / Keydnap entfernt

Um Keydnap v1.5 zu entfernen, beendet man zunächst Transmission. Dann werden mit Hilfe des Activity Monitors alle folgenden Prozesse geschlossen:

- icloudproc
- License.rtf
- icloudsyncd
- /usr/libexec/icloudsyncd -launchd netlogon.bundle

Außerdem sind folgende Dateien und Verzeichnisse zu löschen:

- /Library/Application Support/com.apple.iCloud.sync.daemon/
- /Library/LaunchAgents/com.apple.iCloud.sync.daemon.plist
- /Users/$USER/Library/Application Support/com.apple.iCloud.sync.daemon/
- /Users/$USER/Library/Application Support/com.geticloud/
- /Users/$USER/Library/LaunchAgents/com.apple.iCloud.sync.daemon.plist
- /Users/$USER/Library/LaunchAgents/com.geticloud.icloud.photo.plist

Transmission sollte dann vom System entfernt und von einer vertrauenswürdigen Quelle neu heruntergeladen werden. Die Transmission-Webseite und -Binärdateien werden jetzt auf Github gehostet. Man kann den Hash und die Signatur des berechtigten Binärpaket überprüfen mit:

- "shasum -a 256" Vergleich mit dem Hash auf der Seite und
- "codesign -dvvv" und überprüfen, ob Signatur durch "Digital Ignition LLC" mit Team Identifier 5DPYRBHEAR übereinstimmt.