Wir wurden infiziert...

Hoffentlich haben nun andere Wurmentwickler kein Blut geleckt...
 
Oh, wenn man vom Teufel spricht.
http://www.heise.de/newsticker/meldung/69677 (Meldung von 16:13)

Es geht also los. Im dortigen Forum findet sich noch kein Eintrag....

Nachtrag: Am Besten gefällt mir bislang "der MacOSler trägt heute dunkelrosa...."
 
Hallo

In Safari kann man in den Einstellungen unter "Allgemein" die Option "Sichere Dateien nach dem Öffnen laden" deaktivieren.
Wenn ich nun das Beispiel von Sheep downloade, wird es nicht mehr automatisch entpackt und die enthaltene falsche Bilddatei nicht geladen.
Ähnliche Einstellungen gibt es auch für die diversen anderen Webbrowser.

Um beim Beispiel von Sheep zu bleiben, da wird kein Passwort verlangt, weil es nichts macht, was ein Admin Passwort erfordern würde.

Wenn man Downloads immer auf dem Desktop speichern lässt und die von mir genannte Option deaktiviert hat, kann nichts geladen und ausgeführt werden.

Entpacke ich sheeps Beispieldatei manuell, wird die entpackte Datei nicht ausgeführt.
Schau ich mir die Beispieldatei von sheep vor dem Öffnen genau an (ctrl+klick Informationen), sehe ich dass es keine Bilddatei ist, sondern eine ausführbare Datei.
Hat man die Symbolvorschau aktiviert, ist es schon auffällig wenn das "Bild" keine hat.

Ich glaube wenn man das beachtet, zusätzlich noch unter Systemeinstellungen --> Sicherheit die Option "Kennwort verlangen für die Freigabe von geschützten Systemeinstellungen" aktiviert und nicht mehr alles ohne kurze Prüfung öffnet, kann man auf den Account ohne Admin Rechte verzichten.
Dennoch ist es zweifellos sicherer mit einem Account ohne Admin Rechte zu arbeiten.


Ergänzend erscheint mir der Tip bei Heise sinnvoll:

Als zusätzliche Maßnahme kann man durch geschickte Rechtevergabe verhindern, dass sich der Virus im Verzeichnis /InputManager festsetzen kann:
Legen Sie, falls noch nicht vorhanden, mit dem Programm Terminal das Verzeichnis /Library/InputManagers mit
sudo mkdir /Library/InputManagers
an. Übereignen Sie es mit
sudo chown root:wheel /Library/InputManagers
dem Super-User root und seiner Gruppe wheel. Mit
sudo chmod go-w /Library/InputManagers
stellen Sie sicher, dass nur root etwas hineinschreiben darf. Analog verfahren Sie mit ~/Library/InputManagers. Diese Änderungen beinträchtigen die Funktion bereits vorhandener InputManager nicht. Für diese Vorgehensweise müssen Sie als Administrator angemeldet sein, sudo verlangt außerdem nach einem gültigen Kennwort.


Hier noch eine ergänzende Möglichkeit die im Ambrosia Forum genannt wurde.

If the trojan adds an "apphook" file into /Library/InputManagers/ or
~/Library/InputManagers/
(depending upon whether one is logged in as Admin), would I be correct in thinking that if one did the following, the "apphook" would only be able to be installed with the user's knowledge?

1. If you don't have an InputManagers folder, create one
2. Then control click on the folder and select "enable folder actions"
3. Next, control click the InputManagers folder again and select "attach a folder action".
4. A window will open, click on "add - new item alert"
5. Click choose.

Habe es selbst probiert, so kann nichts in den Ordner /Library/InputManagers/ geschrieben oder darin gelöscht werden, ohne Root Rechte und Passwort.
 
Zuletzt bearbeitet:
bis vor 5 minuten war ich auch noch "Admin". dank der klasse beschreibung hier habe ich jetzt "nur noch" benutzerrechte und habe bisher keine einschränkung feststellen können. muss man als neuer macuser ja erstmal wissen...
 
Hat keiner eine Ahnung, ob man gegen diesen Schädling sich auch über den Schlüsselbund und seine Einstellungen absichern kann??? :rolleyes:
 
Zuletzt bearbeitet:
Thorne^ schrieb:
Entpacke ich sheeps Beispieldatei manuell, wird die entpackte Datei nicht ausgeführt.
Schau ich mir die Beispieldatei von sheep vor dem Öffnen genau an (ctrl+klick Informationen), sehe ich dass es keine Bilddatei ist, sondern eine ausführbare Datei.
Hat man die Symbolvorschau aktiviert, ist es schon auffällig wenn das "Bild" keine hat.
Das stimmt natürlich alles, aber Hand auf's Herz: schaust du dir jede Bilddatei, die du irgendwo runterlädst so genau an (okay, wir die hier mitlesen ab heute vielleicht schon ;))? Mir ist darüber hinaus auch nicht bekannt, ob der Programmierer des Trojaners (oder was auch immer es ist) diese Schwachstellen nicht vielleicht ausgemerzt hat - wenn man sich die Beschreibung der Schadroutine so ansieht, kann er nicht vollkommen unbegabt sein...

Edit: mir scheint gerade, als hätte Heise den "Witz" an der ResFork-Geschichte nicht ganz erkannt - die schreiben nur über das Symbol; dieses allerdings ist eine rein kosmetische Korrektur, der eigentliche Bösewicht steckt doch im "Öffnen mit"-Attribut, nur deshalb wird das vemeintliche Bild mit dem Terminal anstatt der Vorschau geöffnet. Wenn man solche Manipulationen an einzelnen Dateien systemweit verhindern könnte, würde das einen wirksamen Schutz gegen diese Art Angriff gewährleisten.
 
Für mich sieht es nach einer Aktion eines Anti Virus Programm Herstellers aus, der endlich seine bisher vor sich hin staubende Version für Mac OS X in großen Stückzahlen verkaufen möchte.

Apple wird dafür recht schnell ein Bugfix bereitstellen.
 
548.png


alt, aber irgendwie passend.
 
Ach Leute, wisst ihr, was dagegen hilft? Nix!

Irgendwann hackt jemand die Hompage z.B. vom VLC und tarnt seinen Virus als .dmg oder was auch immer und dann hat man all die tollen Tipps hier befolgt, aber weil die Quelle nicht "ominös" erscheint und man sich zum Installieren eines Programmes ja doch wieder als Admin einloggen muss, hat's einen trotzdem erwischt...

C'est la vie, die Windows-Welt kennt das seit 20 Jahren und die leben auch alle noch. Ich selbst empfand Viren in den 10 Jahren meiner PC-Nutzung noch als das kleinste Problem. (ich hatte auch nie einen...)

Weil, wen interessiert denn, ob das System zerschossen wird? Dann setzt man's halt neu auf, das dauert, je nachdem, wieviel man dran rumtweakt, 1-3 Stunden und dann is' auch wieder gut.

Das wirklich unersetzbare sind Daten! Scripte, die den Home-Ordner löschen, gibt's schon ewig. Der beste Schutz dagegen sind Backups. Die helfen auch noch gegen Festplattendefekte, die nach meiner Erfahrung 5x häufiger auftreten, als ein Virenbefall.
 
Thorne^ schrieb:
Für mich sieht es nach einer Aktion eines Anti Virus Programm Herstellers aus, der endlich seine bisher vor sich hin staubende Version für Mac OS X in großen Stückzahlen verkaufen möchte.
daran hab ich auch schon gedacht… :rolleyes:


SpOn macht da schon Andeutungen:
Ob der Virus Schäden anrichtet oder welchen Zweck es hat, wurde nicht mitgeteilt. Für Sophos dürfte bei der Warnung auch eine Rolle spielen, dass Mac-Rechner, die tatsächlich oft noch ohne Virenschutzsoftware sind, einen lukrativen, noch zu erschließenden Markt für die eigenen Produkte darstellen.
http://www.spiegel.de/netzwelt/technologie/0,1518,401356,00.html
 
... "Öffnen mit"-Attribut, nur deshalb wird das vemeintliche Bild mit dem Terminal anstatt der Vorschau geöffnet. Wenn man solche Manipulationen an einzelnen Dateien systemweit verhindern könnte, würde das einen wirksamen Schutz gegen diese Art Angriff gewährleisten.

Ja toll, das wuerde mich aber sehr nerven, wenn ich dann z.B. auf "Vorschau" eingestellte Bilddateien nicht mehr auf "Photoshop" umstellen koennte ...

Also wie bringt man hier Sicherheit und Komfort unter einen Hut?
- Gar nicht.

Das ist ja das nervige an Viren etc.: dass sie NERVEN.

Simon
 
simon.weber schrieb:
Ja toll, das wuerde mich aber sehr nerven, wenn ich dann z.B. auf "Vorschau" eingestellte Bilddateien nicht mehr auf "Photoshop" umstellen koennte ...
Ich bin sicher, den Leuten bei Apple würde eine vernünftige Lösung für dieses Problem einfallen (z.B. dergestalt, dass dieses Attribut nur beachtet wird, wenn es vom Benutzer selber gesetzt wurde) - bei der ganzen Rechtegeschichte haben sie es auch geschafft, ich halte die "Admin"-Lösung für einen äusserst gelungenen Kompromiss zwischen Einfachheit und Sicherheit.

Allerdings sollte man die Geschichte nicht überbewerten, es war für mich eh nur eine Frage der Zeit, bis irgendein Depp auf die Idee kommt, so was zu machen und heisst ja keineswegs, dass bei uns von heute auf morgen plötzlich Zustände wie in der Windows-Hemisphäre Einzug halten werden ;).
 
immerhin steht bei Heise ein workaround:

"Als zusätzliche Maßnahme kann man durch geschickte Rechtevergabe verhindern, dass sich der Virus im Verzeichnis /InputManager festsetzen kann:
Legen Sie, falls noch nicht vorhanden, mit dem Programm Terminal das Verzeichnis /Library/InputManagers mit
sudo mkdir /Library/InputManagers
an. Übereignen Sie es mit
sudo chown root:wheel /Library/InputManagers
dem Super-User root und seiner Gruppe wheel. Mit
sudo chmod go-w /Library/InputManagers
stellen Sie sicher, dass nur root etwas hineinschreiben darf. Analog verfahren Sie mit ~/Library/InputManagers. Diese Änderungen beinträchtigen die Funktion bereits vorhandener InputManager nicht. Für diese Vorgehensweise müssen Sie als Administrator angemeldet sein, sudo verlangt außerdem nach einem gültigen Kennwort."
 
@lundehundt

Der workaround steht übrigens schon in meinem Posting (104) um 16:50Uhr ;) :D
 
Hmmm - ich wollte Schnellschuesse in meinen eigenen Beitraegen eigentlich vermeiden, aber manchal komme ich mit dem Lesen einfach nicht nach :) :D
 
MacApfel schrieb:
minilux schrieb:
das schon, aber hab ich auch Schreibrechte auf /Library/InputManagers ???
(wie gesagt, kanns erst heute abend ausprobieren)
Als Admin ohne sudo:
mkdir: test: Permission denied
Ich hoffe Du hast es wenigstens vorher ausprobiert?

Denn da kommt kein Permission denied. Warum? Weil der Admin überall in /Applications und /Library auch ohne zusätzlichen Authentifizierung schreiben darf. Das Password beim Admin-Account wird nur benötigt, wenn Änderungen in /System vorgenommen werden. Auch für Änderungen in /private wird das Passwort benötigt. Deswegen wird bei Systemupdates immer nach dem Passwort gefragt.

Pingu
 
ich weiss nicht aber, in wie weit die admin-passwortabfragen-geschichte noch relevant ist, denn so weit ich das verstanden habe, braucht das "update_2" diesen trojaners KEINE passwortbestätigung des admins um aktiv zu werden! guck bild & link http://www.fscklog.com/2006/02/os_x_trojaner_t.html
 
Zuletzt bearbeitet:
Pingu schrieb:
Ich hoffe Du hast es wenigstens vorher ausprobiert?

Denn da kommt kein Permission denied. Warum? Weil der Admin überall in /Applications und /Library auch ohne zusätzlichen Authentifizierung schreiben darf.

Nicht in /Library/InputManagers
Habe ich im terminal ausprobiert :)
 
ich würde sagen, apple sollte grundsätzlich alle dienstprogramme über ein passwort laufen lassen. klicke ich ein bild an und öffnet sich terminalfenster, dann weiß ich, dass etwas nicht stimmt. aber ohne passwort kein spielchen.
jedenfalls habe ich erstmal einen neuen admin angelegt namen odin :) und mir selber die rechte entzogen. ich spüre keine veränderung, ausser dass ich halt beim installieren passwort eingeben muss. nach dem abwarten kann man vielleicht das ganze rückgängig machen. sicher ist sicher. jedenfalls kommt mir kein norton drauf, die seuche.
 
Zurück
Oben Unten