Wer seinem System nicht traut, weil er glaubt er habe ein Keylogger drauf, der hat eh andere Probleme als auf einer kompromittierten Kiste ne Rechttrennung weiterzuleben...die bringt dann eh nüscht mehr egal ob UAC an/aus, mit/ohne Adminrechte oder mit/ohne Passwörtern.

"Klick nachstellen" kann bestimmt sogar ich, wenn ich mich ein bisschen einlese.
Passwörter auslesen oder umgehen mit Sicherheit nicht.

Ich traue meinem System durchaus, doch es gibt letztlich keine Garantie, dass ich mir nicht doch irgendwann einen solchen Mist einfange und dann möchte ich, dass ich so gut wie möglich dafür präpariert bin solange einen Schaden zu verhindern, bis meine Sicherheitsprogramme den Bock entdeckt haben.

Um das ganz klar zu verstehen: Wenn ich mir also einen Keylogger einfangen würde, wären die Sicherheitsvorkehrungen, die wir hier diskutieren, nach Deinen Worten hinfällig?

Also ich behaupte einfach mal, (im Falle einer Falschaussage mögen mich die Spezialisten hier berichtigen) das es einfacher ist, einen Code zu programmieren, der einen ButtonKlick aktiviert, als einen Code, der ein Passwort abfängt.
Wenn es bei einer angreifenden Malware vielleicht ein paar Zeilen Code sind, damit dadurch der sagen wir "OK" Button aktiviert wird, dann muss doch eine Malware, die erst dein Passwort abfängt und sich dann mit diesem Passwort in den Adminbereich einloggt, weitaus komplexer sein. Es müsste sich also um die Malware handeln, die das ausführt, wofür sie programmiert wurde, aber gleichzeitig auch noch einen Keylogger enthalten.

Ich nutze die VT von Kaspersky.
Gut, das ist kein Open Source, daher nicht wirklich kontrollierbar.
Aber ich habe mich mich Kaspersky-Forum überzeugen lassen, das die VT von denen sicher gegen Keylogger ist. Wie diese Absicherung allerdings genau funktioniert, weiß ich leider nicht.

Wenn man mal Keylogger oder Screenshot Tools auf dem Rechner hat ist der kompromittiert, dann ist auf diesem Rechner gar nichts mehr sicher.

Dass irgendein Programm- selbst wenn es von Kaspersky ist - effektiv gegen Schadsoftware schützt die mal auf dem Rechner ist bezweifle ich.

Da jegliche per Passwort geschützte Zugänge auf dem Rechner letztendlich per Software geschützt sind können sie letztendlich von einmal installierter (Schad)Software auch ausgehebelt werden.

Mit anderen Worten: wenn das System mal per Keylogger oder Screenshot Fern"wartungs"software kompromittiert ist ist man gekniffen sofern man das nicht merkt und schnell neu installiert.


Trotzdem halte ich den separaten Admin User mit dem separaten Passwort für eine weitere Sicherheitshürde: in dem Falle muss ein Stück Schadsoftware erst eine Lücke in einem Prozess mit Adminrechten finden und per "Privilege Escalation" ausnutzen- was auf einem aktuell gehaltenen System nicht so einfach ist.

Beim "OK" der UAC hat MS zwar Sicherungen eingebaut, aber wer CCC Vorträge auf Youtube sieht findet schnell Beispiele bei denen sie ausgehebelt wird.

Also: UAC ist besser als nichts, Adminkonto mit separatem Passwort ist besser als UAC. Sandbox mit separaten Admin Konto ist dann König (und dürfte in der Praxis sicher genug sein).

Man muss sein Fahrrad ja nicht im Tresor einschließen sondern nur so abschließen dass die Diebe das weniger stark gesicherte Nachbarfahrrad stehlen

Eine Kombination aus Sandbox, Adminkonto, Skript+ Werbeblockern im Browser wäre z.B ein ziemlich gutes Sicherheitkonzept... dann noch Brain.exe dazu, dann ist die Wahrscheinlichkeit von Problemen mit Schadsoftware ziemlich gering... auch wenn es absolute Sicherheit nie geben kann.

Eine Kombination aus Sandbox, Adminkonto, Skript+ Werbeblockern im Browser wäre z.B ein ziemlich gutes Sicherheitkonzept... dann noch Brain.exe dazu, dann ist die Wahrscheinlichkeit von Problemen mit Schadsoftware ziemlich gering... auch wenn es absolute Sicherheit nie geben kann.

Und für ganz wichtige brisante Sachen startet man den Rechner einfach von einem aktuellen Live-Linux...

Das Sicherheitskonzept ist zwar super, mir aber schon wieder zu mühsam. Ich starte meinen Rechner einfach von einem auf der Festplatte aus installierten Linux... das ist auch schon ziemlich sicher da kein Schwein kommerzielle Schadprogramme für ein Betriebssystem schreibt das auf weniger als 2 % aller Desktoprechner benutzt wird....

Mühsam? Für die meisten Leute da draußen ist es schon eine Mammutaufgabe ein Betriebssystem zu installieren...

Also ich behaupte einfach mal, (im Falle einer Falschaussage mögen mich die Spezialisten hier berichtigen) das es einfacher ist, einen Code zu programmieren, der einen ButtonKlick aktiviert, als einen Code, der ein Passwort abfängt.

Diesen Code zu schreiben ist in beiden Fällen eine sehr leichte Übung - je nach verwendeter VB-Version lässt sich mit 5-8 Zeilen eine Tastaturabfrage schreiben, deren String regelmäßig in eine .txt kopiert wird.

Die Schwierigkeit liegt darin, den Code unbemerkt einzuschleusen und die Textdatei auch zu versenden - doch auch dieses Problem ist in beiden Fällen exakt gleich schwierig.....

Liebe Grüße, Alois

Zitat von Alois S

Diesen Code zu schreiben ist in beiden Fällen eine sehr leichte Übung - je nach verwendeter VB-Version lässt sich mit 5-8 Zeilen eine Tastaturabfrage schreiben, deren String regelmäßig in eine .txt kopiert wird.

Die Schwierigkeit liegt darin, den Code unbemerkt einzuschleusen und die Textdatei auch zu versenden - doch auch dieses Problem ist in beiden Fällen exakt gleich schwierig.....

Liebe Grüße, Alois

Dazu müsste aber dieses Script ständig bei Systemstart mitgeladen werden...und solche Standardsachen ohne große Verschleierungen sollte die Virenscanner eigentlich schnell erkennen

Dazu müsste aber dieses Script ständig bei Systemstart mitgeladen werden...und solche Standardsachen ohne große Verschleierungen sollte die Virenscanner eigentlich schnell erkennen

1) Selbst einfachste Keylogger mit Windows Hooks setzen ihren Hook mittlerweile locker vor denen des AV und/oder FW (vor dem "Logon")

2) Etwas bessere laufen im Usermode

3) Und die besten auf tieferer Ebene im Kernelmode

und wenn gleich beim Start die System-dll´s in den RAM kopiert werden - dann laufen sie stets außerhalb jeder Sandbox.....

Liebe Grüße, Alois

Kannst du mal Punkt eins genauer erläutern...
Ich versteh ehrlich gesagt noch noch nicht wie sich Schädlinge ohne Adminrechte im Windows-Start manifestieren können und das bevor sogar die angeblich unverzichtbaren Virenscanner laden

Er wird praktisch als .dll in den RAM geladen, dynamisch verlinkt und dadurch zum systemübergreifenden Hook (etwas vereinfacht ausgedrückt).

Liebe Grüße, Alois

Und das geht alles ohne Adminrechte? Man kann das System ohne Adminrechte so richtig schön verbiegen?

Ja - ich versuche mal, es zu erklären:

Es gibt eine tiefere Registrierungsebene, deren dll´s schon vor dem eigentlichen Systemstart geladen werden;
welche das sind, steht im "CurrentControlSet" unterhalb der Anwendungsebene, die am ehesten noch mit der alten "config.ini" vergleichbar wäre.

Beispiel wäre die gesamte "zuletzt funktionierende Konfiguration", die stets vor dem Systemstart und immer mitgeladen wird - sie ist auch vor dem Start abrufbar, sonst würde dieser Punkt gar nicht funktionieren. - die Adminrechte greifen also erst hinterher.....

Der Clou ist nun der, dass man unter der normalen Oberfläche auch "private" dll´s erstellen und das Flag auf "per runtime" und nicht auf "per start" setzen kann (wie das geht, erklärt Microsoft sogar noch selbst.......)

Und genau das habe ich mit "der Code ist einfach, aber die Implementierung schwierig" gemeint - wobei das Wörtchen "schwierig" dabei sehr relativ ist.....

Liebe Grüße, Alois