Trojaner Locky verschlüsselt munter Benutzerdaten

[minilux]

backupd/backupd-helper etc. laufen als root.

gut. das heisst, ich kann als User nicht lesend und schreibend auf die TC zugreifen? Weil: backup und backupd-helper laufen auch bei likalen Backupplatten als root. Trotzdem kann ich auf die Platten zugreifen -- lesend und schreibend

 

[kermitd]

Noch zu meinem vorigen Beitrag: klar...Skripte sind natürlich irgendwie immer Textdokumente (wenn sie nicht (vor-)kompiliert sind), aber dann in der Regel trotzdem als Skript erkennbar. Also das sichtbare Dokument ist auch das was ausgeführt wird.


Und bzgl. des mehrmaligen "Abnickens": Auch da kann man Windows den Vorwurf machen die Nutzer darauf trainiert zu haben einfach überall direkt ok und danke zu drücken damit man irgendwie weiter kommt. Da gibt es ja auch andere Möglichkeiten den Benutzer vor sich selbst zu schützen.

gut. das heisst, ich kann als User nicht lesend und schreibend auf die TC zugreifen? Weil: backup und backupd-helper laufen auch bei likalen Backupplatten als root. Trotzdem kann ich auf die Platten zugreifen -- lesend und schreibend

Also so sieht es bei mir aus:

drwxr-xr-x 5 root wheel ... Time Machine Backups

drwxr-xr-x+ 6 root wheel ... Backups.backupdb

 

[kermitd]

Das gleiche gilt übrigens für die MobileBackups die ein normaler Nutzer auch nicht deaktivieren können sollte (man korrigiere mich falls nötig). Möglicherweise ließen sich bereits von dort Dateien wiedergewinnen. Unter Windows ist locky ja offensichtlich in der Lage die shadow copies zu löschen.

 

[Olivetti]

hier kommen ja auch oft empfehlungen an user, nicht noch andere dateien neben tm zu speichern.

was zeigt denn

find /Volumes/TM-Volume -user "$USER" -exec echo {} \; -exec bash -c 'ls -ld "${@%/*}"' bash {} \; -exec echo "---" \;

(wenn, dann zeigt es jeweils die rechte des ordners einer fundstelle [ls -ld .])

 

[kermitd]

Ich selber benutze keine Time Capsule sondern Time Machine über AFP. Basiert aber natürlich auf ähnlichem Prinzip mit dem sparsebundle.

 

[kermitd]

An den Unterordnern verhindert OS X denke ich die Änderung zusätzlich zu ACLs durch eine Sicherheitsmaßnahme

edit: Insofern war erst recht natürlich mein Verweis (bloß) auf die UNIX Permissions unzureichend.

 

[stonefred]

Hier eine Lösung Windows-Fileserver zu schützen Windows FileServer vor Ransomware / Crypto Locker schützen Vermutlich kann Locky eher keine Shadowcopies auf Servern löschen.

 

[Olivetti]

@kermitd
ja, das müssen sie machen, weil ihnen tm sonst wegen der directory-hardlinks um die ohren fliegt.
und um das auszuhebeln ist root gefragt.
---
trotzdem, lass doch mal #284 auf dein tm-sparsebundle laufen.


@stonefred
ich sehe das aber erstmal als paniklösung. dauerhaft kann so ja nicht gearbeitet werden.

den "Resourcen-Manager für Dateiserver" gibt's leider nur für die serverversionen. aber besser als nix.

 

[stonefred]

ich sehe das aber erstmal als paniklösung. dauerhaft kann so ja nicht gearbeitet werden.

Stimmt. Könnte aber a) effektiv sein und b) die IT alamieren mit Username des Verursachers.

den "Resourcen-Manager für Dateiserver" gibt's leider nur für die serverversionen. aber besser als nix.

Für Frontends gibts das Antiramsomwaretool. Trojaner Locky verschlüsselt munter Benutzerdaten Hört sich vielversprechend an, wenn auch leider nur Betastatus. Habe auch noch Cryptoprevent gefunden.

 

[kermitd]

Hm... Möglicherweise ist VBA unter dem Mac doch besser abgesichert als unter Windows? Mir war auch gar nicht bewusst, dass Word 2016, jedenfalls die Hauptanwendung, auf dem Papier unter OS X ja sogar in der Sandbox läuft. Ich schaffe es in einem Makro zwar eine Anwendung (in Words Sandbox-Container) herunterzuladen, aber es ist nicht möglich extended attributes (über xattr -d com.apple.quarantine) zu entfernen geschweige denn die App ohne Warnung auszuführen. Jedenfalls naive Ansätze über MacScript und do shell script schlagen fehl. Ich kenn mich leider mit VBA überhaupt nicht aus. Vielleicht kann da mal jemand mit mehr Erfahrung ein paar Tests fahren?

 

[Der Reisende]

So ein quatsch. Tritt am Mac was auf, wird Brain 2.0 empfohlen. Am Windowsrechner, wo man aktiv einen Anhang aus unbekannter Quelle öffnet, dann in Word noch mal bestätigt dass man das Dokument öffnen will, und dann noch mal bestätigt, dass man die Makros aktiviert, da ist dann Windows schuld.

Du hast die Kern-Aussage nicht verstanden. Nicht Windows ist Schuld, Windows ist anfällig für diese Atacken.

 

[Ezekeel]

Du hast die Kern-Aussage nicht verstanden. Nicht Windows ist Schuld, Windows ist anfällig für diese Atacken.

Beim Mac ist das doch rein von der Architektur nicht anders. Einzig die geringe Verbreitung schützt.

 

[bernie313]

Beim Mac ist das doch rein von der Architektur nicht anders. Einzig die geringe Verbreitung schützt.

You make my day, der Lacher schlechthin.

 

[Ezekeel]

You make my day, der Lacher schlechthin.

Wieso? Wenn ich 3x bei Hinweisen auf potentielle Risiken dennoch auf "Ja, ich will!" klicke. Wo ist der Unterschied? Und Deppen, die das machen gibt es unter OS X zuhauf. Ich erinnere nur an die iWork-Malware, den Mac Defender, die zahlreichen Threads hier im Forum zu Malware.

Ja, von Haus aus ist OS X sicherer. Aber wenn man mit gesundem Menschenverstand an die Sache ran geht, bei Windows mit entsprechenden Benutzerrechten agiert, das System und wichtige Software aktuell hält ist alles in Ordnung. Bei den Szenarien, die hier manchmal gefahren werden sollte man meinen wir wären noch im Jahr 1995...

 

[Der Reisende]

Gehn wir mal vom durchschnitts Nutzer aus. Mail erhalten, Mail öffnen, Inhalt kryptisch formuliert und nicht schlüssig aber suggestiv = Angebotenen Anhang zum besseren Verständnis öffnen. Haben halt nicht alle `nen 1ser Abschluss und sind unfehlbar. Das Problem ist doch nicht die Anfälligkeit eines Systems. Das Problem ist die kriminelle Energie der Arschlöcher die diese Kacke produzieren.

 

[kermitd]

Hm... Möglicherweise ist VBA unter dem Mac doch besser abgesichert als unter Windows? Mir war auch gar nicht bewusst, dass Word 2016, jedenfalls die Hauptanwendung, auf dem Papier unter OS X ja sogar in der Sandbox läuft. Ich schaffe es in einem Makro zwar eine Anwendung (in Words Sandbox-Container) herunterzuladen, aber es ist nicht möglich extended attributes (über xattr -d com.apple.quarantine) zu entfernen geschweige denn die App ohne Warnung auszuführen. Jedenfalls naive Ansätze über MacScript und do shell script schlagen fehl. Ich kenn mich leider mit VBA überhaupt nicht aus. Vielleicht kann da mal jemand mit mehr Erfahrung ein paar Tests fahren?

VBA Improvements in Office 2016 :

As Office 2016 for Mac is sandboxed, users are prompted to grant access every time a file access request is made. GrantAccessToMultipleFilesis a command that takes an array of file pointers and helps minimize the number of these prompts.

Sandboxing also severely breaks the previously existing MacScript command that allows the use of inline AppleScript in Visual Basic. This is where AppleScriptTask can help. Users can store an AppleScript file at a specified location on the disk and use AppleScriptTask within VB to invoke it. The location of these scripts is specified by the operating system and cannot be altered.

The MAC_OFFICE_VERSION conditional lets macros determine what version of Mac Office the user is running. This comes handy in cases where certain commands (like the two above) are available only on a given version, and invoking them on another version may result in errors.

Since Office 2016 for Mac Beta, we’ve been keeping close watch on issues relating to these new commands and have been making fixes. With this update, we’re releasing some important fixes that will considerably improve the overall performance of these commands. In particular, we’ve fixed various timeout issues related to AppleScriptTask.

Unlike VB macros in Office for Mac 2011, VB macros in Office 2016 for Mac don’t have access to external files by default. The Office 2016 for Mac apps are sandboxed and so they lack the required permissions to access external files.

Genial. War mir wie gesagt überhaupt nicht klar, da Office ja nicht dazu gezwungen ist (wie es der Fall wäre, wenn MS es über den App Store vertriebe).

 

[minilux]

Du hast die Kern-Aussage nicht verstanden. Nicht Windows ist Schuld, Windows ist anfällig für diese Atacken.

Das Problem ist doch nicht die Anfälligkeit eines Systems...

Ich kann heute einen Mac User ein Shell Skript schicken, dass die Festplatte löscht. Wenn die Dumpfbacke darauf hereinfällt, ist Mac OS genauso viel oder wenig "anfällig".

 

[kermitd]

Ich kann heute einen Mac User ein Shell Skript schicken, dass die Festplatte löscht. Wenn die Dumpfbacke darauf hereinfällt

Viel Erfolg!

 

[Olivetti]

um's xattr -d ... kommst da nicht rum.

wie schaut's aus, wenn du die datei mit curl holst?

 

[kermitd]

wie schaut's aus, wenn du die datei mit curl holst?

Genauso