Discussion:
Scareware-Befall
(zu alt für eine Antwort)
Michael Paul
2010-07-22 08:32:13 UTC
Permalink
Hallo,

im Bekanntenkreis hat es die halbwüchsige Tochter des Hauses
"geschafft", einen dieser Fake-Virenscanner namens "Security Tool" zu
installieren.
System ist ein XP Home SP3 auf aktuellem Patchstand, und es wird ein
Account mit eingeschränkten Benutzerrechten verwendet.

Dieses "Security Tool"-Ding wurde in "All Users" installiert und
mittlerweile entsorgt, allerdings fand ich im eigentlichen Userprofil
weitere - möglicherweise nachgeladene - Malwarekomponenten, die laut
jotti.org ebenfalls der Kategorie "Fake.AV" zuzuordnen sind.

Diverse Beschreibungen von "Security Tool" erwähnen auch Veränderungen
der Hosts-Datei sowie diverser Registry-Schlüssel. Aufgrund der
Verwendung eines Nicht-Administrativen Benutzerkontos sind diese
Veränderungen nicht auf dem System vorhanden.

Autostart-Einträge der Malware (die u.a. auch den Taskplaner zu nutzen
scheint) waren nur für das Benutzerprofil zu entdecken.

Meiner Auffassung nach sollte es doch ausreichend sein, das befallene
Benutzerprofil zu löschen, um die Kiste wieder sauber zu kriegen,
oder?

Danke schonmal,
Michael

P.S.: Ich weiß, mit SAFER wäre das nicht passiert. ;-)
Thomas Dreher
2010-07-22 11:05:30 UTC
Permalink
Post by Michael Paul
Hallo,
im Bekanntenkreis hat es die halbwüchsige Tochter des Hauses
"geschafft", einen dieser Fake-Virenscanner namens "Security Tool" zu
installieren.
System ist ein XP Home SP3 auf aktuellem Patchstand, und es wird ein
Account mit eingeschränkten Benutzerrechten verwendet.
Dieses "Security Tool"-Ding wurde in "All Users" installiert und
mittlerweile entsorgt, allerdings fand ich im eigentlichen Userprofil
weitere - möglicherweise nachgeladene - Malwarekomponenten, die laut
jotti.org ebenfalls der Kategorie "Fake.AV" zuzuordnen sind.
Diverse Beschreibungen von "Security Tool" erwähnen auch Veränderungen
der Hosts-Datei sowie diverser Registry-Schlüssel. Aufgrund der
Verwendung eines Nicht-Administrativen Benutzerkontos sind diese
Veränderungen nicht auf dem System vorhanden.
Autostart-Einträge der Malware (die u.a. auch den Taskplaner zu nutzen
scheint) waren nur für das Benutzerprofil zu entdecken.
Meiner Auffassung nach sollte es doch ausreichend sein, das befallene
Benutzerprofil zu löschen, um die Kiste wieder sauber zu kriegen,
oder?
Sofern keine Privilege-escalation stattgefunden hat, ja. Aber das
auszuschließen dürfte sich als schwierig erweisen. Ich bin in Sachen
Windows nicht wirklich so fit, aber User, die die Hosts und
Registry-Schlüssel ändern können, sind mir nicht geheuer. War das ein
"Hauptbenutzer"-Account?


Gruß

Thomas
Michael Paul
2010-07-22 11:35:34 UTC
Permalink
Hi,
Post by Thomas Dreher
Post by Michael Paul
im Bekanntenkreis hat es die halbwüchsige Tochter des Hauses
"geschafft", einen dieser Fake-Virenscanner namens "Security Tool" zu
installieren.
[...]
Post by Thomas Dreher
Post by Michael Paul
Diverse Beschreibungen von "Security Tool" erwähnen auch Veränderungen
der Hosts-Datei sowie diverser Registry-Schlüssel. Aufgrund der
Verwendung eines Nicht-Administrativen Benutzerkontos sind diese
Veränderungen nicht auf dem System vorhanden.
[...]
Post by Thomas Dreher
Post by Michael Paul
Meiner Auffassung nach sollte es doch ausreichend sein, das befallene
Benutzerprofil zu löschen, um die Kiste wieder sauber zu kriegen,
oder?
Sofern keine Privilege-escalation stattgefunden hat, ja. Aber das
auszuschließen dürfte sich als schwierig erweisen. Ich bin in Sachen
Windows nicht wirklich so fit, aber User, die die Hosts und
Registry-Schlüssel ändern können, sind mir nicht geheuer.
*zustimm*
Der Benutzer gehörte aber glücklicherweise nicht zu dieser
privilegierten Gruppe. Registry-Schlüssel muß man differenziert
betrachten, es gibt diverse Zweige der Registry, die - gewollt - für
Benutzer schreibbar sind.

Vielleicht habe ich mich mißverständlich ausgedrückt.
Die Hosts-Datei war auf dem betroffenen System unverändert, auch die
von diversen Quellen genannten Registry-Einträge, die die Dreckware
sonst zu schreiben pflegt, waren nicht vorhanden. Eben weil der
Benutzer zur Gruppe der "Eingeschränkten" gehört.
Post by Thomas Dreher
War das ein "Hauptbenutzer"-Account?
Nein. Normaler, "eingeschränkter" Benutzer. Von daher hatte die
Malware keine Möglichkeit, die beschriebenen Systemveränderungen
vorzunehmen. Der Dreck lag in "All Users" und im Benutzerprofil
(einschließlich der für den jeweiligen Benutzer beschreibbaren
Registry-Zweige (irgendwelche Run-Schlüssel) sowie dessen Liste der
geplanten Tasks).

Gruß und Danke,
Michael
Michael Lawnick
2010-07-22 11:49:44 UTC
Permalink
Post by Michael Paul
Nein. Normaler, "eingeschränkter" Benutzer. Von daher hatte die
Malware keine Möglichkeit, die beschriebenen Systemveränderungen
vorzunehmen.
Das hört sich gut an.
Post by Michael Paul
Der Dreck lag in "All Users"
Das allerdings nicht.
Da darf er eigentlich keine Schreibrechte haben.
Unbedingt alle Links in diesem Verzeichnis prüfen und beten.
Oder eben besser: die Standardprozedur.
--
Gruß,
auch Michael
Michael Paul
2010-07-22 13:30:27 UTC
Permalink
Post by Michael Lawnick
Post by Michael Paul
Nein. Normaler, "eingeschränkter" Benutzer. Von daher hatte die
Malware keine Möglichkeit, die beschriebenen Systemveränderungen
vorzunehmen.
Das hört sich gut an.
Post by Michael Paul
Der Dreck lag in "All Users"
Das allerdings nicht.
Da darf er eigentlich keine Schreibrechte haben.
In einigen Unterverzeichnissen wie "Dokumente" oder "Anwendungsdaten"
darf er offenbar Dateien und Verzeichnisse anlegen, auf die er als
"Owner" Vollzugriff hat. Jetzt bin ich mir nicht mehr ganz sicher, ob
die Dreckware direkt unter "All Users" oder "All Users
\Anwendungsdaten" abgelegt war.
Post by Michael Lawnick
Unbedingt alle Links in diesem Verzeichnis prüfen und beten.
Ich checke das nochmal. Danke. Beten muß ich nicht, ich bin "nur der
Supportmensch" ;-)
Post by Michael Lawnick
Oder eben besser: die Standardprozedur.
Das wäre dann die Ultima Ratio ;->
In Erwägung gezogen habe ich das schon. Nur würde ich diesen Aufwand
einschließlich Fahrerei nach Möglichkeit gerne vermeiden (ist nicht
mein Rechner).

Gruß,
Michael
Stefan Kanthak
2010-07-22 20:11:27 UTC
Permalink
Post by Michael Lawnick
Post by Michael Paul
Nein. Normaler, "eingeschränkter" Benutzer. Von daher hatte die
Malware keine Möglichkeit, die beschriebenen Systemveränderungen
vorzunehmen.
Das hört sich gut an.
Post by Michael Paul
Der Dreck lag in "All Users"
Das allerdings nicht.
Da darf er eigentlich keine Schreibrechte haben.
Bei den Home-Versionen schon, ebenso wenn unter den Professional-
Versionen die "Einfache xxx-Freigabe" verwendet wird: dann dienen
die "Eigenen Dateien"^WDokumente von "All Users" als allen Benutzern
zugaenglicher und beschreibbarer Datenaustauschbereich.
Post by Michael Lawnick
Unbedingt alle Links in diesem Verzeichnis prüfen und beten.
Oder eben besser: die Standardprozedur.
Dummerweise verwenden Programme wie Microsoft Security Essentials
(eigentlich richtig) "%AllUsersProfile%\Anwendungsdaten\..." zur
Ablage ihrer Daten, in diesem Fall die Virenerkennungsmuster.

Falls dort Schreibzugriff bestand: VORSICHT!

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Michael Paul
2010-07-26 21:37:16 UTC
Permalink
Hi,
Am 22.7.10 schrieb Stefan Kanthak:
[...]
Post by Stefan Kanthak
Bei den Home-Versionen schon, ebenso wenn unter den Professional-
Versionen die "Einfache xxx-Freigabe" verwendet wird: dann dienen
die "Eigenen Dateien"^WDokumente von "All Users" als allen Benutzern
zugaenglicher und beschreibbarer Datenaustauschbereich.
Die einfache Dateifreigabe ist bei den Systemen, die ich aufgesetzt habe
(XP Home und Pro), abgeschaltet. Trotzdem kann ohne weiteren Eingriff ein
eingeschränkter Benutzer schreibend auf die "Gemeinsamen Dateien"
zugreifen.
Post by Stefan Kanthak
Dummerweise verwenden Programme wie Microsoft Security Essentials
(eigentlich richtig) "%AllUsersProfile%\Anwendungsdaten\..." zur
Ablage ihrer Daten, in diesem Fall die Virenerkennungsmuster.
Falls dort Schreibzugriff bestand: VORSICHT!
Genau dort (All Users\Anwendungsdaten\...) bestand Schreibzugriff (soweit
ich das verstanden habe, ist das Windows-Grundeinstellung).
Interessanterweise scheint das auch für %windir%\temp zutreffend zu sein
:-(
Worauf muß ich hier achten, von Dateien mit verdächtigen Namen abgesehen?

Gruß,
Michael
Stefan Kanthak
2010-07-27 13:58:52 UTC
Permalink
Post by Michael Paul
Hi,
[...]
Post by Stefan Kanthak
Bei den Home-Versionen schon, ebenso wenn unter den Professional-
Versionen die "Einfache xxx-Freigabe" verwendet wird: dann dienen
die "Eigenen Dateien"^WDokumente von "All Users" als allen Benutzern
zugaenglicher und beschreibbarer Datenaustauschbereich.
Die einfache Dateifreigabe ist bei den Systemen, die ich aufgesetzt habe
(XP Home und Pro), abgeschaltet. Trotzdem kann ohne weiteren Eingriff ein
eingeschränkter Benutzer schreibend auf die "Gemeinsamen Dateien"
zugreifen.
Ja, die ACLs von "%AllUsersProfile%\Dokumente\" sind nach Installation
(leider) so gesetzt. Du kannst sie aber aendern. AFAIK werden sie jedoch
beim Einschalten der "Einfachen xxx-Freigabe" wieder auf Standardwerte
zurueckgesetzt.
Post by Michael Paul
Post by Stefan Kanthak
Dummerweise verwenden Programme wie Microsoft Security Essentials
(eigentlich richtig) "%AllUsersProfile%\Anwendungsdaten\..." zur
Ablage ihrer Daten, in diesem Fall die Virenerkennungsmuster.
Falls dort Schreibzugriff bestand: VORSICHT!
Genau dort (All Users\Anwendungsdaten\...) bestand Schreibzugriff (soweit
ich das verstanden habe, ist das Windows-Grundeinstellung).
Wieder richtig.
Aber nicht alle dort angelegten Unterverzeichnisse uebernehmen die ACLs,
und nicht alle dort abgelegten Dateien werden von Prozessen mit hoeheren
Rechten benutzt.
Du musst im Einzelfall pruefen, ob der Benutzer irgendwelche Dateien
veraendert haben koennte, die von Prozessen mit hoeheren Rechten benutzt
werden, wodurch "privilege escalation" moeglich wuerde.
Post by Michael Paul
Interessanterweise scheint das auch für %windir%\temp zutreffend zu sein
:-(
Dummerweise ja, und zudem noch voellig ueberfluessig! Jeder Benutzer hat
seit Windows 2000 sein eigenes %TEMP% unterhalb seines Benutzerprofils.

Sieh Dir aber auch die ACLs von %SystemRoot%\Debug\UserMode\ sowie
%SystemRoot%\CSC\, %SystemRoot%\System32\Spool\Printers\ und
%SystemRoot%\Tasks\ an (und dann noch meine XP_SAFER.INF.-).
Post by Michael Paul
Worauf muß ich hier achten, von Dateien mit verdächtigen Namen abgesehen?
S.o.: die Moeglichkeit der "privilege escalation".
Sei es durch Ausfuehren eines "Programms" (direkt als *.EXE, indirekt
z.B. ueber RUNDLL32.EXE, als Codec, ...), oder Ausnutzen einer Luecke,
wie aktuell im IconHandler von Verknuepfungen.

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Michael Paul
2010-07-27 19:42:39 UTC
Permalink
Hi,
[...]
Post by Stefan Kanthak
Post by Michael Paul
Die einfache Dateifreigabe ist bei den Systemen, die ich aufgesetzt habe
(XP Home und Pro), abgeschaltet. Trotzdem kann ohne weiteren Eingriff ein
eingeschränkter Benutzer schreibend auf die "Gemeinsamen Dateien"
zugreifen.
Ja, die ACLs von "%AllUsersProfile%\Dokumente\" sind nach Installation
(leider) so gesetzt.
Über das "leider" könnte man trefflich streiten. Die Nutzung dieses
Verzeichnisses als gemeinsame Datenablage ist für mich okay.
Post by Stefan Kanthak
Post by Michael Paul
Post by Stefan Kanthak
Dummerweise verwenden Programme wie Microsoft Security Essentials
(eigentlich richtig) "%AllUsersProfile%\Anwendungsdaten\..." zur
Ablage ihrer Daten, in diesem Fall die Virenerkennungsmuster.
Falls dort Schreibzugriff bestand: VORSICHT!
Genau dort (All Users\Anwendungsdaten\...) bestand Schreibzugriff (soweit
ich das verstanden habe, ist das Windows-Grundeinstellung).
Wieder richtig.
Aber nicht alle dort angelegten Unterverzeichnisse uebernehmen die ACLs,
So ganz kann ich Dir jetzt nicht folgen.
Wenn ich als eingeschränkter Benutzer "User" dort einen Ordner anlege, dann
haben alle angemeldeten Benutzer Lese-, Schreib- und Ausführungsrechte.
Für Dateien in diesem Verzeichnis haben alle anderen Benutzer (damit meine
ich die Gruppe der "Benutzer") Lese- und Ausführungs-, aber keine
Schreibrechte.
Im Eigenschaftsdialog des Objekts steht unter "Sicherheit": 'Diese
Berechtigung wird vom übergeordneten Objekt vererbt'.

Meinst Du vielleicht mit
Post by Stefan Kanthak
Aber nicht alle dort angelegten Unterverzeichnisse uebernehmen die ACLs,
daß es dort auch Verzeichnisse mit von diesem Schema abweichenden ACLs
gibt, wie beispielsweise der "Microsoft"-Ordner? Dort hat die Gruppe
"Benutzer" (fast) nur Lese- und Ausführungsrechte.

Das hier
Post by Stefan Kanthak
und nicht alle dort abgelegten Dateien werden von Prozessen mit hoeheren
Rechten benutzt.
leuchtet mir hingegen ein. Meine TV-Software beispielsweise benutzt ein
Verzeichnis unter "All Users"\Anwendungsdaten für bestimmte, vom Anwender
änderbare Parameter.
Post by Stefan Kanthak
Du musst im Einzelfall pruefen, ob der Benutzer irgendwelche Dateien
veraendert haben koennte, die von Prozessen mit hoeheren Rechten benutzt
werden, wodurch "privilege escalation" moeglich wuerde.
Danke. Wenn das ...\Anwendungsdaten-Verzeichnis beim Patienten genauso
übersichtlich ist wie bei mir, dann sollte das relativ problemarm sein.
Post by Stefan Kanthak
Post by Michael Paul
Interessanterweise scheint das auch für %windir%\temp zutreffend zu sein
:-(
Dummerweise ja, und zudem noch voellig ueberfluessig! Jeder Benutzer hat
seit Windows 2000 sein eigenes %TEMP% unterhalb seines Benutzerprofils.
Ja eben. Reingucken darf ich (als unprivilegierter Benutzer) nicht, aber
Daten und Programme ablegen und ausführen. *grummel*
Post by Stefan Kanthak
Sieh Dir aber auch die ACLs von %SystemRoot%\Debug\UserMode\ sowie
%SystemRoot%\CSC\, %SystemRoot%\System32\Spool\Printers\ und
%SystemRoot%\Tasks\ an
urgs.
Post by Stefan Kanthak
(und dann noch meine XP_SAFER.INF.-).
:-)

Nochmals Danke,
Michael
Stefan Kanthak
2010-07-28 12:52:58 UTC
Permalink
Post by Michael Paul
Hi,
[...]
Post by Michael Paul
Post by Stefan Kanthak
Post by Michael Paul
Genau dort (All Users\Anwendungsdaten\...) bestand Schreibzugriff (soweit
ich das verstanden habe, ist das Windows-Grundeinstellung).
Wieder richtig.
Aber nicht alle dort angelegten Unterverzeichnisse uebernehmen die ACLs,
So ganz kann ich Dir jetzt nicht folgen.
[...]
Post by Michael Paul
Meinst Du [damit] daß es dort auch Verzeichnisse mit von diesem Schema
abweichenden ACLs gibt, wie beispielsweise der "Microsoft"-Ordner?
Dort hat die Gruppe "Benutzer" (fast) nur Lese- und Ausführungsrechte.
Ich meine die nicht einheitliche Vererbung der ACLs von
"%AllUsersProfile%\Anwendungsdaten\" auf die direkten Unterverzeichnisse.

[...]

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Heiko Schlenker
2010-07-22 11:42:56 UTC
Permalink
Post by Michael Paul
Meiner Auffassung nach sollte es doch ausreichend sein, das befallene
Benutzerprofil zu löschen, um die Kiste wieder sauber zu kriegen,
oder?
Um zu prüfen, ob die Kiste wieder sauber ist, müsste der Zustand vor
der Kompromittierung bekannt sein. Anderenfalls gäbe es keine
Vergleichsgrundlage, sodass es sich schlecht sagen ließe, was exakt
am System verändert worden ist. Die Gefahr wäre also groß, eine
"Hintertür" zu übersehen.

Tipps:
- http://oschad.de/wiki/index.php/Kompromittierung
http://www.malte-wetz.de/index.php?viewPage=sec-compromise.html
http://www.cert.org/tech_tips/win-UNIX-system_compromise.html
http://faq.underflow.de/#SECTION000120000000000000000
http://faq.jors.net/virus.html
- http://www.microsoft.com/technet/security/secnews/articles/gothacked.mspx
http://www.microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx
- http://www.netzwelt.de/news/70253-trojaner-paedophil-wider-willen.html
- http://www.malte-wetz.de/index.php/?viewPage=sec-removal.html
http://www.heise.de/security/Reinigen-oder-Plattmachen--/artikel/47520
- http://groups.google.com/groups?as_umsgid=***@mid.deneb.enyo.de
in Verbindung mit http://www.microsoft.com/technet/community/columns/secmgmt/sm0504.mspx
bzw. http://technet.microsoft.com/en-us/library/cc512587.aspx

Gruß, Heiko
Michael Landenberger
2010-07-22 15:40:27 UTC
Permalink
Die Gefahr wäre also groß, eine "Hintertür" zu übersehen.
Da es die Malware nicht einmal geschafft hat, in die für ihr Funktionieren
notwendigen Registry-Keys zu schreiben oder Systemdateien zu verändern, gehe
ich davon aus, dass sie keine Privilege Escalation beherrscht (sonst wäre es
ein Leichtes gewesen, sich die entsprechenden Schreibrechte zu verschaffen).
Ohne Privilege Escalation kann eine Malware aber auf einem System mit
eingeschränkten Rechten kaum etwas ausrichten. Ich denke daher, dass es in
diesem Fall reicht, die Verzeichnisse zu säubern, für die auch einfache
Benutzer Schreibrechte haben.

Gruß

Michael
Juergen P. Meier
2010-07-23 04:24:46 UTC
Permalink
Post by Michael Landenberger
Die Gefahr wäre also groß, eine "Hintertür" zu übersehen.
Da es die Malware nicht einmal geschafft hat, in die für ihr Funktionieren
notwendigen Registry-Keys zu schreiben oder Systemdateien zu verändern, gehe
ich davon aus, dass sie keine Privilege Escalation beherrscht (sonst wäre es
ein Leichtes gewesen, sich die entsprechenden Schreibrechte zu verschaffen).
Ohne Privilege Escalation kann eine Malware aber auf einem System mit
eingeschränkten Rechten kaum etwas ausrichten. Ich denke daher, dass es in
diesem Fall reicht, die Verzeichnisse zu säubern, für die auch einfache
Benutzer Schreibrechte haben.
Welchen Teil genau von
| Dieses "Security Tool"-Ding wurde in "All Users" installiert
hast du nicht verstanden?
Michael Landenberger
2010-07-23 10:55:27 UTC
Permalink
Post by Juergen P. Meier
Welchen Teil genau von
| Dieses "Security Tool"-Ding wurde in "All Users" installiert
hast du nicht verstanden?
Welchen Teil von "Ich denke daher, dass es in diesem Fall reicht, die
Verzeichnisse zu säubern, für die auch einfache Benutzer Schreibrechte
haben." hast du nicht verstanden?

Hinweis für Leute wie dich, die sich mit Windows nicht auskennen: in "All
Users" bzw. in einigen Unterverzeichnissen davon haben in der Regel alle
Benutzer Schreibrechte (daher auch der Name "All Users"), also auch einfache
Benutzer.

Gruß

Michael
Juergen P. Meier
2010-07-24 10:57:07 UTC
Permalink
Post by Michael Landenberger
Post by Juergen P. Meier
Welchen Teil genau von
| Dieses "Security Tool"-Ding wurde in "All Users" installiert
hast du nicht verstanden?
Welchen Teil von "Ich denke daher, dass es in diesem Fall reicht, die
Verzeichnisse zu säubern, für die auch einfache Benutzer Schreibrechte
haben." hast du nicht verstanden?
Du Irrst dich. Da du darauf einen gefaehrlichen Tip fuer den OP
ableitest, sollte das nicht kommentarlos stehen bleiben.

An den OP: Nicht auf Michael Landenberger hoeren!

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Wilfried Kramer
2010-07-25 17:22:51 UTC
Permalink
Post by Juergen P. Meier
Post by Michael Landenberger
Post by Juergen P. Meier
Welchen Teil genau von
| Dieses "Security Tool"-Ding wurde in "All Users" installiert
hast du nicht verstanden?
Welchen Teil von "Ich denke daher, dass es in diesem Fall reicht, die
Verzeichnisse zu säubern, für die auch einfache Benutzer Schreibrechte
haben." hast du nicht verstanden?
Du Irrst dich.
Worin genau irrt Michael denn?
Etwa in dem Abschnitt, den Du im Zitat weggelassen hast?



Wilfried
--
Was soll bloss eine Signatur?
Na gut, nehmen wir sie zum Test:
ae=ä, oe=ö, ue=ü, Ae=Ä, Oe=Ö, Ue=Ü, sz=ß!
Was noch??
Wolfgang Ewert
2010-07-25 21:10:24 UTC
Permalink
Post by Juergen P. Meier
Post by Michael Landenberger
Die Gefahr wäre also groß, eine "Hintertür" zu übersehen.
Da es die Malware nicht einmal geschafft hat, in die für ihr Funktionieren
notwendigen Registry-Keys zu schreiben oder Systemdateien zu verändern, gehe
ich davon aus, dass sie keine Privilege Escalation beherrscht
...
Post by Juergen P. Meier
Post by Michael Landenberger
Ich denke daher, dass es in
diesem Fall reicht, die Verzeichnisse zu säubern, für die auch einfache
Benutzer Schreibrechte haben.
Welchen Teil genau von
| Dieses "Security Tool"-Ding wurde in "All Users" installiert
hast du nicht verstanden?
siehe MID: <i2abgs$dkh$03$***@news.t-online.com> von Stefan, Stichwort:
Home-Version.

HTH
Wolfgang
Juergen P. Meier
2010-07-23 04:21:31 UTC
Permalink
Post by Michael Paul
im Bekanntenkreis hat es die halbwüchsige Tochter des Hauses
"geschafft", einen dieser Fake-Virenscanner namens "Security Tool" zu
installieren.
http://faq.jors.net/virus.html
Post by Michael Paul
Meiner Auffassung nach sollte es doch ausreichend sein, das befallene
Benutzerprofil zu löschen, um die Kiste wieder sauber zu kriegen,
oder?
Die Komponente, die dafuer sorgte, dass die lokalen Privilegien
eskaliert wurden und so (u.A.) die entdeckte Komponente Systemweit
installierte, hast du noch nicht gefunden. Ergo kannst du nicht von
einer erfolgreichen Saeuberung ausgehen.

Warum vergleichst du nicht das System mit der sauberen Referenz, oder
spielst das Backup ein?
Post by Michael Paul
P.S.: Ich weiß, mit SAFER wäre das nicht passiert. ;-)
Was hat das mit systematischen Schwaechen des verwendeten
Betriebsystems zu tun?
Michael Landenberger
2010-07-23 11:00:07 UTC
Permalink
Post by Juergen P. Meier
Die Komponente, die dafuer sorgte, dass die lokalen Privilegien
eskaliert wurden
Es wurden keine lokalen Privilegien eskaliert. Zum Schreiben in "All Users"
reichen auch einfache Benutzerrechte.

Gruß

Michael
Heiko Schlenker
2010-07-23 11:57:37 UTC
Permalink
Post by Michael Landenberger
Post by Juergen P. Meier
Die Komponente, die dafuer sorgte, dass die lokalen Privilegien
eskaliert wurden
Es wurden keine lokalen Privilegien eskaliert.
Woher weißt Du das? ;-) Ist der Schädling und der evtl. nachgeladene
Code daraufhin analysiert worden? Ist der aktuelle Systemzustand mit
einem vor der Kompromittierung verglichen worden?

Gruß, Heiko
Ralph Lehmann
2010-07-23 13:55:45 UTC
Permalink
Post by Heiko Schlenker
Post by Michael Landenberger
Post by Juergen P. Meier
Die Komponente, die dafuer sorgte, dass die lokalen Privilegien
eskaliert wurden
Es wurden keine lokalen Privilegien eskaliert.
Woher weißt Du das? ;-)
<***@mid.uni-berlin.de>
Heiko Schlenker
2010-07-23 21:24:44 UTC
Permalink
Post by Heiko Schlenker
Post by Michael Landenberger
Post by Juergen P. Meier
Die Komponente, die dafuer sorgte, dass die lokalen Privilegien
eskaliert wurden
Es wurden keine lokalen Privilegien eskaliert.
Woher weißt Du das? ;-)
Aha, es geht in Richtung Wunschdenken. Motto: "Augen zu und durch.
Wird schon gut gehen. Ist ja nicht mein System."

SCNR, Heiko
Michael Landenberger
2010-07-23 22:12:54 UTC
Permalink
Post by Heiko Schlenker
Aha, es geht in Richtung Wunschdenken.
Nö. Es geht in Richtung gesunder Menschenverstand. Den hat auch schon der OP
bewiesen, indem er seinem Töchterchen keine Admin-Rechte eingeräumt hat. Wie
war das nochmal: "nicht mit Admin-Rechten zu arbeiten ist ein guter Schutz
gegen Malware-Befall"?
Post by Heiko Schlenker
Motto: "Augen zu und durch.
Wird schon gut gehen. Ist ja nicht mein System."
Wenn es mein System wäre, hätte ich das Problem nicht.

Gruß

Michael
Heiko Schlenker
2010-07-23 22:53:30 UTC
Permalink
Post by Michael Landenberger
Post by Heiko Schlenker
Aha, es geht in Richtung Wunschdenken.
Nö. Es geht in Richtung gesunder Menschenverstand.
Nö, vielmehr in Richtung Mutmaßung bzw. Hoffung. :-)

Dabei wären Nachweise doch einigermaßen "einfach" zu erbringen, z.B.
durch Vergleich des aktuellen Systemzustands mit dem vor der
Kompromittierung, durch Analyse des Schadcodes usw.

Gruß, Heiko
Michael Landenberger
2010-07-23 23:40:39 UTC
Permalink
Post by Heiko Schlenker
Nö, vielmehr in Richtung Mutmaßung bzw. Hoffung. :-)
Mutmaßen und Hoffen muss jeder, der irgendeine Software einsetzt.
Post by Heiko Schlenker
Dabei wären Nachweise doch einigermaßen "einfach" zu erbringen,
z.B. durch Vergleich des aktuellen Systemzustands mit dem vor der
Kompromittierung, durch Analyse des Schadcodes usw.
Alle verdächtigen ausführbaren Dateien aus "All Users" zu löschen ist
wesentlich einfacher. Theoretisch könnte man "All Users" auch einfach so
lassen wie es ist, denn ohne die Möglichkeit in Registry und Systemdateien
zu schreiben, überlebt kein Prozess einen Reboot, also auch kein
Malware-Prozess.

Gruß

Michael
Heiko Schlenker
2010-07-24 00:50:34 UTC
Permalink
Post by Michael Landenberger
Alle verdächtigen ausführbaren Dateien aus "All Users" zu löschen ist
wesentlich einfacher.
Klar ist es einfacher, bloß das trojanische Pferd wieder durch das
Stadttor hinauszuschieben, statt sich auf die mühsame Suche nach
möglichen Unholden zu machen, die womöglich in dessen Bauch saßen,
und zu ermitteln, was diese in der Zwischenzeit so alles angestellt
haben. ;)

Gruß, Heiko
Michael Landenberger
2010-07-24 08:09:43 UTC
Permalink
Post by Heiko Schlenker
Klar ist es einfacher, bloß das trojanische Pferd wieder durch
das Stadttor hinauszuschieben,
Bei einem Trojanischen Pferd in einer Stadt, in der Griechen (und auch das
Pferd selbst) mangels Admin-Rechte verhungern, reicht das, ja.

Gruß

Michael
Heiko Schlenker
2010-07-24 10:06:10 UTC
Permalink
Post by Michael Landenberger
Post by Heiko Schlenker
Klar ist es einfacher, bloß das trojanische Pferd wieder durch
das Stadttor hinauszuschieben,
Bei einem Trojanischen Pferd in einer Stadt, in der Griechen (und auch das
Pferd selbst) mangels Admin-Rechte verhungern, reicht das, ja.
Woher nimmst Du die Gewissheit, dass sie sich nicht inzwischen mit
Nahrung (Admin-Rechte) versorgt haben? Tja, und so schließt sich der
Kreis. :-)

Gruß, Heiko
Ralph Lehmann
2010-07-24 18:14:00 UTC
Permalink
Post by Heiko Schlenker
Post by Michael Landenberger
Bei einem Trojanischen Pferd in einer Stadt, in der Griechen (und auch das
Pferd selbst) mangels Admin-Rechte verhungern, reicht das, ja.
Woher nimmst Du die Gewissheit, dass sie sich nicht inzwischen mit
Nahrung (Admin-Rechte) versorgt haben? Tja, und so schließt sich der
Kreis. :-)
Der Kreis schließt sich - allerdings ausschließlich in Deinem Kopf -
immer nach dem gleichen Schema. Blöd ist halt nur, dass das Schema zu
einfach ist und deshalb auf den hier besprochenen Fall nicht passt.

HINT: Wald- und Wiesen Trojaner, die sich die Mühe machen, an
Admin-Rechte zu gelangen, sind derzeit überhaupt nicht unterwegs. Denn
das wäre ziemlich unwirtschaftlich, da es nicht darauf ankommt, jedes
einzelne potentielle Opfer zu entführen. Es reicht vielmehr die breite
Masse der Benutzer, die ohnehin immer Admin sind.

"Cyber"-Kriminelle sind nun mal keine Idioten - in der Regel können sie
rechnen.
Heiko Schlenker
2010-07-24 23:07:05 UTC
Permalink
Post by Ralph Lehmann
Post by Heiko Schlenker
Post by Michael Landenberger
Bei einem Trojanischen Pferd in einer Stadt, in der Griechen (und auch das
Pferd selbst) mangels Admin-Rechte verhungern, reicht das, ja.
Woher nimmst Du die Gewissheit, dass sie sich nicht inzwischen mit
Nahrung (Admin-Rechte) versorgt haben? Tja, und so schließt sich der
Kreis. :-)
Der Kreis schließt sich - allerdings ausschließlich in Deinem Kopf -
immer nach dem gleichen Schema.
Statt wortreiche Ausflüchte zu schreiben, könnte man auch einfach so
ehrlich sein und sagen, dass keine Gewissheit vorliegt, dass man
sich auch nicht die Mühe machen will, dem abzuhelfen und dass man
lediglich hofft, der Schädling habe keine weiteren Schäden
verursacht. ;-)

Gruß, Heiko
Helmut Hullen
2010-07-25 05:25:00 UTC
Permalink
Hallo, Heiko,
Post by Heiko Schlenker
Post by Ralph Lehmann
Post by Heiko Schlenker
Post by Michael Landenberger
Bei einem Trojanischen Pferd in einer Stadt, in der Griechen (und
auch das Pferd selbst) mangels Admin-Rechte verhungern, reicht
das, ja.
Woher nimmst Du die Gewissheit, dass sie sich nicht inzwischen mit
Nahrung (Admin-Rechte) versorgt haben? Tja, und so schließt sich
der Kreis. :-)
Der Kreis schließt sich - allerdings ausschließlich in Deinem Kopf -
immer nach dem gleichen Schema.
Statt wortreiche Ausflüchte zu schreiben, könnte man auch einfach so
ehrlich sein und sagen, dass keine Gewissheit vorliegt,
Gewissheit gibt es nie.

Viele Gruesse!
Helmut
Ralph Lehmann
2010-07-25 08:36:29 UTC
Permalink
Post by Heiko Schlenker
Post by Ralph Lehmann
Post by Heiko Schlenker
Post by Michael Landenberger
Bei einem Trojanischen Pferd in einer Stadt, in der Griechen (und auch das
Pferd selbst) mangels Admin-Rechte verhungern, reicht das, ja.
Woher nimmst Du die Gewissheit, dass sie sich nicht inzwischen mit
Nahrung (Admin-Rechte) versorgt haben? Tja, und so schließt sich der
Kreis. :-)
Der Kreis schließt sich - allerdings ausschließlich in Deinem Kopf -
immer nach dem gleichen Schema.
Statt wortreiche Ausflüchte zu schreiben,
Offenbar sind Argumente, die Deinen Überzeugungen widersprechen, per
Definition "Ausflüchte".
Post by Heiko Schlenker
könnte man auch einfach so
ehrlich sein und sagen, dass keine Gewissheit vorliegt, dass man
sich auch nicht die Mühe machen will, dem abzuhelfen und dass man
lediglich hofft, der Schädling habe keine weiteren Schäden
verursacht. ;-)
Exakt. Genauso wenig, wie ich mir die Mühe mache, nach einem
gewöhnlichen Wohnungseinbruch sämtliche Räume nach nuklearem
Sprengstoff, Wanzen des CIA, Antrax sowie Aliens abzusuchen.

Natürlich ist das grob fahrlässig, weil ich so nicht mit absoluter
Gewissheit sagen kann, dass derlei Dinge nicht installiert wurden!11
Toni Grass
2010-07-25 09:17:55 UTC
Permalink
Post by Ralph Lehmann
Exakt. Genauso wenig, wie ich mir die Mühe mache, nach einem
gewöhnlichen Wohnungseinbruch sämtliche Räume nach nuklearem
Sprengstoff, Wanzen des CIA, Antrax sowie Aliens abzusuchen.
[....]

Solltest Du aber. Ich kann mich da an einige Filme erinnern, wo der Held
besser dran gewesen wäre, hätte er's getan...

Toni (todernst)
--
Infolge des gekürzten Budgets und der gestiegenen Unkosten für Gas,
Öl und Strom wurde das Licht am Ende des Tunnels abgeschaltet. Wir
bedauern die dadurch entstandenen Unanehmlichkeiten.
Heiko Schlenker
2010-07-25 15:18:28 UTC
Permalink
Post by Ralph Lehmann
Post by Heiko Schlenker
Post by Ralph Lehmann
Post by Heiko Schlenker
Post by Michael Landenberger
Bei einem Trojanischen Pferd in einer Stadt, in der Griechen (und auch das
Pferd selbst) mangels Admin-Rechte verhungern, reicht das, ja.
Woher nimmst Du die Gewissheit, dass sie sich nicht inzwischen mit
Nahrung (Admin-Rechte) versorgt haben? Tja, und so schließt sich der
Kreis. :-)
Der Kreis schließt sich - allerdings ausschließlich in Deinem Kopf -
immer nach dem gleichen Schema.
Statt wortreiche Ausflüchte zu schreiben,
Offenbar sind Argumente, die Deinen Überzeugungen widersprechen, per
Definition "Ausflüchte".
Es wurde behauptet, der Schädling habe sich keine weitreichenden
Zugriffsrechte besorgt. Das Argument (Begründung der Behauptung)
lautet: Mutmaßung. Das ist wenig überzeugend. Auch auf Nachfrage
wurden keine stichhaltigen Belege angeführt. Selbst dann nicht,
nachdem eine Vorgehensweise, wie die Belege gewonnen werden könnten,
kurz umrissen worden ist. Durch markigen Worte oder Versuche,
Diskussionspartner zu diskreditieren, wird die "Argumentation" nicht
schlüssiger. Ganz im Gegenteil.

Gruß, Heiko
Ralph Lehmann
2010-07-25 16:16:22 UTC
Permalink
Post by Heiko Schlenker
Post by Ralph Lehmann
Offenbar sind Argumente, die Deinen Überzeugungen widersprechen, per
Definition "Ausflüchte".
Es wurde behauptet, der Schädling habe sich keine weitreichenden
Zugriffsrechte besorgt. Das Argument (Begründung der Behauptung)
lautet: Mutmaßung.
Es ist allgemein bekannt, dass das Leben voll von Mutmaßungen ist. Diese
unterscheiden sich allerdings erheblich voneinander, was ihre Annäherung
an die Realität angeht.
Post by Heiko Schlenker
Das ist wenig überzeugend.
Das wäre genau dann wenig überzeugend, wenn zum einen die Malware selbst
als auch die Konfiguration des Zielsystems nebst dem Verhalten des
Systemverantwortlichen darauf schließen lassen würden.

Dem ist allerdings nicht so.
Post by Heiko Schlenker
Auch auf Nachfrage
wurden keine stichhaltigen Belege angeführt.
Der OP hat sich über die Wirkungsweise des Schädlings ausführlich
informiert. Bitte lies nochmal das Eingangsposting.
Post by Heiko Schlenker
Selbst dann nicht,
nachdem eine Vorgehensweise, wie die Belege gewonnen werden könnten,
kurz umrissen worden ist.
Du meinst wie in <***@humbert.ddns.org> beschrieben?
Das setzt voraus, dass der Systemzustand vor dem Ereignis bekannt ist.
Ist er aber nicht.

BTW: Hast Du einen solchen Vergleich schon einmal in der Praxis
angestellt? Und danach aufgrund des Ergebnisses entschieden Daumen
'runter oder auch Daumen hoch?

IMO ist so etwas in der Praxis überhaupt nicht durchführbar.
Post by Heiko Schlenker
Durch markigen Worte oder Versuche,
Diskussionspartner zu diskreditieren,
Du zeigst mir bitte die Diskreditierung.
Post by Heiko Schlenker
wird die "Argumentation" nicht
schlüssiger. Ganz im Gegenteil.
Dann versuche ich es nochmals anders, obwohl Dich das wahrscheinlich
auch nicht überzeugen wird:

1. Das Zielsystem wurde mit eingeschränkten Rechten betrieben.
2. Zur Kompromittierung wäre privilege escalation notwendig gewesen.
3. Im Zusammenhang mit der genannten Malware war in einschlägigen Listen
und Foren von privilege escalation nichts zu lesen, obwohl die
Wirkungsweise des Schädlings ansonsten sehr ausführlich analysiert wurde.

Daraus folgt, dass die Möglichkeit einer bleibenden Kompromittierung
durch privilege escalation gegen Null geht. (Sie ist deutlich niedriger
als z.B. das Risiko, sich von einer gehackten Herstellerwebsite einen
verseuchten Treiber herunterzuladen. Das gab es in der Praxis übrigens
schon ...)

Glaube mir: Wenn der genannte Schädling solche nicht alltäglichen
Fähigkeiten hätte, wüsste ich das, weil ich es gelesen hätte.
Wilfried Kramer
2010-07-25 17:27:56 UTC
Permalink
Post by Heiko Schlenker
Post by Ralph Lehmann
Post by Heiko Schlenker
Statt wortreiche Ausflüchte zu schreiben,
Offenbar sind Argumente, die Deinen Überzeugungen widersprechen, per
Definition "Ausflüchte".
Es wurde behauptet, der Schädling habe sich keine weitreichenden
Zugriffsrechte besorgt. Das Argument (Begründung der Behauptung)
lautet: Mutmaßung.
Unsinn.
Der bekannt Schädling beschreibt u.a. bestimmte Keys in der Registry.
Das hat er nicht getan, womit man davon ausgehen darf, daß er dazu nicht
in der Lage war.
Weil er aber nach Privilege Elevation dazu in der Lage gewesen wäre,
darf man wiederum davon ausgehen, daß genau das nicht der Fall war.

Anders herum weiß man auch nicht, ob das System vorher sauber war.



Wilfried
--
Type NUL:
Heiko Schlenker
2010-07-26 05:41:22 UTC
Permalink
Post by Wilfried Kramer
Post by Heiko Schlenker
Post by Ralph Lehmann
Post by Heiko Schlenker
Statt wortreiche Ausflüchte zu schreiben,
Offenbar sind Argumente, die Deinen Überzeugungen widersprechen, per
Definition "Ausflüchte".
Es wurde behauptet, der Schädling habe sich keine weitreichenden
Zugriffsrechte besorgt. Das Argument (Begründung der Behauptung)
lautet: Mutmaßung.
Unsinn.
Der bekannt Schädling beschreibt u.a. bestimmte Keys in der Registry.
Das hat er nicht getan, womit man davon ausgehen darf, daß er dazu nicht
in der Lage war.
Weil er aber nach Privilege Elevation dazu in der Lage gewesen wäre,
darf man wiederum davon ausgehen, daß genau das nicht der Fall war.
Vorsicht! Rein von der Logik her beschreibst Du im Grunde genommen
eine Abduktion[1], jedoch keine Deduktion oder Induktion. Anders
formuliert: Es kann sein, dass der Schädling nicht mit
weitreichenden Zugriffsrechten ausgestattet war (Abduktion). Es muss
aber nicht der Fall sein (Deduktion). Oder ob es tatsächlich so
gewesen ist, ist unklar (Induktion). Das Risiko ist recht hoch, dass
die Schlussfolgerung falsch ist. Daher ist die Beweiskraft nicht
besonders ausgeprägt. Eigentlich liegt eine bloße Vermutung vor.

Eine goldene Regel der Sicherheit in der Informationstechnik lautet
sinngemäß: Solange unbekannt ist, was im Zuge einer Kompromittierung
so alles am System verändert worden ist -- der Zustand des Systems ist
also undefiniert -- kann nicht konservativ genug vorgegangen werden.
Alles andere wäre ziemlich fahrlässig bzw. ein Spiel mit dem Feuer.
In der Praxis würden solche Systeme i.d.R. platt gemacht und neu
aufgesetzt werden.


[1] Die Grenze zum Sophismus (logischer Scheinbeweis bzw.
beabsichtigter Trugschluss) ist fließend. :-)

Gruß, Heiko
Michael Landenberger
2010-07-26 11:32:36 UTC
Permalink
Post by Heiko Schlenker
Eine goldene Regel der Sicherheit in der Informationstechnik
lautet sinngemäß: Solange unbekannt ist, was im Zuge einer
Kompromittierung so alles am System verändert worden ist
Und die platinene Regel lautet: wenn es gar keine Kompromittierung gegeben
hat, dann muss auch die goldene Regel nicht angewandt werden.

Gruß

Michael
Heiko Schlenker
2010-07-26 11:50:40 UTC
Permalink
Post by Michael Landenberger
Post by Heiko Schlenker
Eine goldene Regel der Sicherheit in der Informationstechnik
lautet sinngemäß: Solange unbekannt ist, was im Zuge einer
Kompromittierung so alles am System verändert worden ist
Und die platinene Regel lautet: wenn es gar keine Kompromittierung
gegeben hat, dann muss auch die goldene Regel nicht angewandt
werden.
Das setzt natürlich voraus, dass mit Sicherheit festgestellt werden
kann, ob eine Kompromittierung stattgefunden hat oder nicht. Ist
Schadecode eingedrungen und kann eine Kompromittierung nicht
ausgeschlossen werden, dann ist vom schlimmsten Fall auszugehen.

Merke:
"Law #1: If a bad guy can persuade you to run his program on your
computer, it's not your computer anymore."
(Quelle: <http://www.microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx>)

Gruß, Heiko
Helmut Hullen
2010-07-26 12:07:00 UTC
Permalink
Hallo, Heiko,
Post by Heiko Schlenker
Post by Michael Landenberger
Und die platinene Regel lautet: wenn es gar keine Kompromittierung
gegeben hat, dann muss auch die goldene Regel nicht angewandt
werden.
Das setzt natürlich voraus, dass mit Sicherheit festgestellt werden
kann, ob eine Kompromittierung stattgefunden hat oder nicht. Ist
Schadecode eingedrungen und kann eine Kompromittierung nicht
ausgeschlossen werden, dann ist vom schlimmsten Fall auszugehen.
Und auch bei einer Neu-Installation kann Schadecode mit eingebaut
werden. Deshalb ist es am besten, den Rechner zu schreddern.

Ach ja: wenn ich das Haus verlasse, dann könnte mir ein Ziegelstein auf
den Kopf fallen.

Wenn ich das Haus nicht verlasse, dann könnte einer der
Rettungshubschrauber, die zwischen der Autobahn und der Unfallklinik
pendeln, auf unser Haus abstürzen.

Wenn ich zum Frühstück ein Schinkenbrötchen esse, ...

Viele Gruesse!
Helmut
Ansgar -59cobalt- Wiechers
2010-07-26 14:01:48 UTC
Permalink
Post by Heiko Schlenker
Post by Michael Landenberger
Post by Heiko Schlenker
Eine goldene Regel der Sicherheit in der Informationstechnik
lautet sinngemäß: Solange unbekannt ist, was im Zuge einer
Kompromittierung so alles am System verändert worden ist
Und die platinene Regel lautet: wenn es gar keine Kompromittierung
gegeben hat, dann muss auch die goldene Regel nicht angewandt
werden.
Das setzt natürlich voraus, dass mit Sicherheit festgestellt werden
kann, ob eine Kompromittierung stattgefunden hat oder nicht. Ist
Schadecode eingedrungen und kann eine Kompromittierung nicht
ausgeschlossen werden, dann ist vom schlimmsten Fall auszugehen.
Die Abwesenheit jeglicher Indizien für eine Kompromittierung ausserhalb
des Zugriffsbereichs des (eingschränkten) Benutzers darf als hinreichend
sicher angesehen werden.

cu
59cobalt
--
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq
Michael Paul
2010-07-26 21:25:40 UTC
Permalink
Am 25.7.10 schrieb Heiko Schlenker:
[...]
Post by Heiko Schlenker
Es wurde behauptet, der Schädling habe sich keine weitreichenden
Zugriffsrechte besorgt.
Zumindest war der Dreck nur dort, wo eingeschränkte Benutzer per Default
Schreibrechte haben. Das betrifft auch "All Users\Anwendungsdaten".
Üblicherweise erstellt die Schadsoftware auch Registry-Einträge, die
systemweit gelten (HKLM usw.). Das ist nicht passiert wegen der fehlenden
Rechte.

Ich weiß, dies ist kein Beweis dafür, daß nicht doch irgendwelcher Dreck
sich mit Hilfe von "Privilege Escalation" ganz tief im System eingenistet
haben könnte. Beobachten konnte ich nichts dergleichen, aber ein Rootkit
kann ich natürlich nicht ausschließen.


Michael
Heiko Schlenker
2010-07-26 23:25:47 UTC
Permalink
Post by Michael Paul
Ich weiß, dies ist kein Beweis dafür, daß nicht doch irgendwelcher
Dreck sich mit Hilfe von "Privilege Escalation" ganz tief im System
eingenistet haben könnte. Beobachten konnte ich nichts dergleichen,
aber ein Rootkit kann ich natürlich nicht ausschließen.
Genau das ist der Knackpunkt.

Durch Vergleich mit einem Systemzustand vor der Kompromittierung
könnte recht schnell ermittelt werden, ob weitere Änderungen am
System vorliegen. Fehlt diese Vergleichsmöglichkeit, dann ist ein
gehöriges Maß an computerforensisches Know-how und Zeit nötig, um
weitere Manipulationen des Systems als die bislang gefundenen
ausschließen zu können. Mit Beten, Hoffen und Bangen ist's
jedenfalls nicht getan. Auch wenn's bequemer wäre. :-)

Gruß, Heiko
Michael Paul
2010-07-27 19:46:28 UTC
Permalink
Hi,
Post by Heiko Schlenker
Post by Michael Paul
Ich weiß, dies ist kein Beweis dafür, daß nicht doch irgendwelcher
Dreck sich mit Hilfe von "Privilege Escalation" ganz tief im System
eingenistet haben könnte. Beobachten konnte ich nichts dergleichen,
aber ein Rootkit kann ich natürlich nicht ausschließen.
Genau das ist der Knackpunkt.
(...)
Post by Heiko Schlenker
Mit Beten, Hoffen und Bangen ist's
jedenfalls nicht getan. Auch wenn's bequemer wäre. :-)
Dem Besitzer des Rechners habe ich schon signalisiert, daß es keine gute
Idee ist, mit dem Ding noch sensible Dinge wie Homebanking zu machen.
Die Entscheidung, das Ding neu aufzusetzen (Image des
"Auslieferungszustandes" existiert) oder "gesäubert" weiterzubetreiben,
obliegt nun ihm.

Gruß,
Michael
Juergen P. Meier
2010-07-24 10:56:53 UTC
Permalink
Post by Michael Landenberger
Post by Juergen P. Meier
Die Komponente, die dafuer sorgte, dass die lokalen Privilegien
eskaliert wurden
Es wurden keine lokalen Privilegien eskaliert. Zum Schreiben in "All Users"
reichen auch einfache Benutzerrechte.
Das ist Falsch.
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Wolfgang Ewert
2010-07-25 21:14:47 UTC
Permalink
Post by Juergen P. Meier
Post by Michael Landenberger
Post by Juergen P. Meier
Die Komponente, die dafuer sorgte, dass die lokalen Privilegien
eskaliert wurden
Es wurden keine lokalen Privilegien eskaliert. Zum Schreiben in "All Users"
reichen auch einfache Benutzerrechte.
Das ist Falsch.
Du kennst das System?
Auch ich habe punktuell in bestimmten solchen Hierarchien Schreibrechte
eingeräumt, hier lag es nach MID: <i2abgs$dkh$03$***@news.t-online.com>
einfach an der Version (Home).

Gruß
Wolfgang
Stefan Kanthak
2010-07-23 13:01:10 UTC
Permalink
Post by Juergen P. Meier
Post by Michael Paul
im Bekanntenkreis hat es die halbwüchsige Tochter des Hauses
"geschafft", einen dieser Fake-Virenscanner namens "Security Tool" zu
installieren.
Die Komponente, die dafuer sorgte, dass die lokalen Privilegien
eskaliert wurden
Dies kann ausgeschlossen werden, da keine Schreibzugriffe des Schaedlings
in System-Verzeichnisse oder -Registryschluessel entdeckt wurden.
Post by Juergen P. Meier
und so (u.A.) die entdeckte Komponente Systemweit installierte,
Du phantasierst!
Post by Juergen P. Meier
hast du noch nicht gefunden. Ergo kannst du nicht von
einer erfolgreichen Saeuberung ausgehen.
Post by Michael Paul
P.S.: Ich weiß, mit SAFER wäre das nicht passiert. ;-)
Was hat das mit systematischen Schwaechen des verwendeten
Betriebsystems zu tun?
Welche systematischen Schwaechen?

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Loading...