This post originated from an RSS feed registered with .NET Buzz
by -.
Original Post: Hilfe! Ich werde verändert!
Feed Title: Norbert Eder - Living .NET
Feed URL: http://feeds.feedburner.com/NorbertEder-Livingnet
Feed Description: Copyright (c)2005, 2006 by Norbert Eder
Im Artikel Ich werde beklaut! habe ich darüber geschrieben, wie einfach Ressourcen aus einer WPF-Anwendung entwendet werden können und warum es sich - aus meiner Sicht - nicht lohnt, diese Inhalte mit hohem Aufwand zu schützen.
Nun ist das Stehlen von Ressourcen (Layouts, Styles, Grafiken, etc.) wohl eine der häufigsten Arten, aber nicht die Schlimmste. Seltener, aber dennoch nicht zu unterschätzen ist es, wenn Software von Fremden bewußt verändert wird. Für viele Anwendungsbereiche mag das vielleicht kaum eine Relevanz haben, aber gerade im Security-Bereich kann dies äußerst unangenehme Folgen mit sich bringen. Aber wie kann man sich davor schützen?
Strong Named Assemblies
Der erste Ansatz ist, den eigenen Assemblies einen Strong Name zu verpassen. Die Identität der Assembly besteht hierbei aus ihrem Namen, der Versionsnummer und Informationen der Kultur (sofern diese gesetzt wurde) inklusive eines öffentlichen Schlüssels (Public Key), als auch einer digitalen Signatur. Dies ist ein einfacher Weg, der frei Haus durch .NET mitgeliefert wird, hat jedoch so seine Tücken als dass ein Strong Name sehr einfach entfernt werden kann. Danach kann die Software normal verwendet und auch verändert werden. Die veränderte Assembly kann zwar ohne Signatur nicht im den Global Assembly Cache (GAC) installiert werden, was aber in vielen Fällen auch nicht vorgesehen ist.
Nichts desto trotz sollte Strong Named Signing dennoch verwendet werden, da es doch eine zusätzliche Hürde darstellt und es daher für viele weniger attraktiv ist, die Software zu verändern. Alle Angreifer können damit allerdings nicht ausgeschlossen werden.
Wie vor Veränderung schützen?
Ein vollständiger Schutz ist nie möglich. Man kann es dem Angreifer aber erheblich schwerer machen. Es gibt zahlreiche Tools, die hier Abhilfe schaffen wollen. In diesem Zusammenhang werden oft Obfuscating-Tools genannt, die jedoch nicht vor Veränderung schützen. Andere Produkte fahren weit größere Geschütze auf. Eines davon ist CodeVeil. Dieses Tool bietet nicht nur Obfuscating-Mechanismen, sondern verschlüsselt zusätzlich auch MSIL. Weiters werden entschlüsselte Informationen nicht im selben Speicherbereich der Assembly geladen, wodurch eine Speicher-Dump erheblich erschwert wird.
Es gibt also durchaus Mechanismen, um sich bestmöglich zu schützen. Eine 100%ige Garantie wird es allerdings nie geben. Man kann also immer nur versuchen, einen Schritt vor den bösen Jungs zu sein bzw. es ihnen so schwer zu machen, dass die Attraktivität, die Software zu manipulieren, möglichst gering ist.
Wichtig ist zusätzlich, dass man sich als Entwickler über die Möglichkeiten der Angreifer informiert. Einen interessanten Einstieg bietet hier der Artikel Assembly Manipulation and C#/VB.NET Code Injection.
PS: Viele Tools unterstützen in den aktuellen Versionen weder WPF noch Silverlight. Hier bleibt zu hoffen, dass die Hersteller Mittel und Wege finden, uns Entwickler auch bei diesen Technologien mit Security zu unterstützen.
Previous Topic
