Zusammenfassung
Sie glauben, Access sei sicher? Lassen Sie sich eines Besseren belehren!
Techniken
MDE, Sicherheitssystem
Voraussetzungen
Access 97 und höher
Wie (un)sicher ist Access?
Karl Donaubauer, Wien
Ein wichtiger Aspekt für manche Anwendungen ist der Schutz von Daten, Objekten, Entwurfsansichten und Code vor unerwünschtem Zugriff. Access hat in dieser Hinsicht keinen guten Ruf, und das zu Recht. Als letzte Bastion sind nun die MDEs gefallen.
Access-Sicherheitssystem
Access bietet traditionell mehrere Methoden der Absicherung. Die am einfachsten zu implementierende ist auch am einfachsten zu knacken: Das Datenbankkennwort. Es ist in allen Access-Versionen relativ leicht im Binärcode der MDB auffindbar. Deshalb gibt es im Internet unzählige Knack-Tools, mit denen alle möglichen Leute versuchen, Geld zu verdienen.
Etwas schwieriger ist das korrekt und vollständig eingerichtete Sicherheitssystems von Access zu überwinden. Die Betonung liegt auf "korrekt und vollständig". Das Vorgehen zum Absichern einer Datenbank ist relativ kompliziert und die Anleitungen so dürftig oder schwer auffindbar, dass viele Anwender schon daran scheitern.
So werden zum Beispiel dem Administrator oft nicht die Rechte entzogen, noch öfter wird der Eigentümer der Datenbank nicht geändert. Solcherart "geschützte" Anwendungen sind natürlich offen wie Scheunentore.
Selbst wenn alle Maßnahmen zur Sicherung richtig durchgeführt wurden, samt eigener MDW, Verschlüsselung und so weiter, ist das Access-Sicherheitssystem nur ein Gartenzaun, der eher symbolisch Privatbesitz anzeigt und Unbedarfte abwehren kann, aber keine ernsthaften Angriffe. Dabei besteht der Aufwand für den Angreifer lediglich in einer kurzen Webrecherche und etwas Geld, das er für ein Knacktool ausgeben muss. Ich habe im Laufe der Zeit einige dieser Tools getestet und festgestellt, dass es dabei alle Abstufungen an Brauchbarkeit gibt. Von manchen nur sehr eingeschränkt funktionierenden bis zu wenigen, die wirklich für jede Version von Access und gegen alle Varianten von Schutz funktionieren.
Jedem ernsthaften Access-Entwickler sollte klar sein, dass sich auch das korrekt und vollständig implementierte Access-Sicherheitssystem definitiv knacken lässt, dass Tools dafür im Internet leicht zu finden sind und nur ein paar Dutzend Euro kosten. Wenn Sie sich schon einmal intensiv mit diesem Thema befasst haben, sind das wohl keine Neuigkeiten für Sie. Anders sieht es wahrscheinlich mit dem nächsten Kapitel aus.
MDE
Beim Umwandeln in eine MDE wird der Textcode aus der Datenbank entfernt und durch vorkompilierten sogenannten P-Code ersetzt. Seit Einführung der MDEs mit Access 97, also immerhin zehn Jahre lang, galt daher in der Access-Welt, dass man seinen Programmcode durch das Umwandeln der MDB in eine MDE zuverlässig schützen konnte.
Manche Entwickler glaubten auch, so könnten sie ihre Entwürfe für Formulare und Berichte abschotten. Das konnte aber von jeher durch das Durchlaufen der Eigenschaften-Auflistungen und Neuerstellen der Objekte umgangen werden. Dafür gibt es ebenfalls seit Jahren fertige Tools im Web. Als wirkliche Neuerung erschien im vorigen Jahr das kommerzielle Angebot einer britischen Webseite, nicht nur die Entwürfe aus einer MDE, sondern auch den VBA-Code wieder zugänglich zu machen.
Auf www.everythingaccess.com bietet die Firma iTech Masters diesen Service an. Hinter der Firma ist bisher nur ein Mann namens Wayne Phillips konkret auszumachen.
Abb. 1: Einverständnis mit dem Reverse Engineering
Reverse Engineering von
MDE-Dateien
Nun wird im Internet ja allerhand behauptet und für Geld angeboten. Deshalb habe ich vor einiger Zeit beschlossen, zu testen, ob die Firma hält, was sie verspricht. Mein russischer Access-MVP-Kollege Alex Dybenko hatte bereits länger Kontakt zu Wayne Phillips. Deshalb habe ich ihn als Mittelsmann für den Test eingesetzt. Phillips erklärte sich bereit, eine MDE mit bis zu 30 Standard- und Klassenmodulen testweise und kostenlos in eine MDB zurückzuverwandeln.
Ich habe für den Test eine MDE von knapp 2 MB im Format von Access XP erstellt. Sie enthielt Auszüge aus einer meiner aktuellen Anwendungen, nämlich eine weitgehend funktionierende Kombination aus Formularen und Berichten. Dazu kamen einige extra hineinkopierte Standard- und Klassenmodule mit API-Aufrufen und so weiter, um die MDE wirklich zu einem Gradmesser für die Qualität der Dekompilierleistung zu machen.
Eine weitere Bedingung von iTech Masters war, dass ich an den Anfang jedes Modules eine Text-Konstante zu setzen hatte, in der ich iTech Masters ausdrücklich das Recht fürs Reverse Engineering des Codes einräumte (s. Abb. 1).
Die Form einer Konstanten war deshalb notwendig, weil das einzige, was nicht mehr aus dem P-Code herauszuholen ist, die Kommentare sind, die man in den Textcode setzen kann. Diese Kommentare werden schon beim Vorkompilieren aus der Datenbank entfernt und sind daher nicht mehr in der MDE enthalten. Konstanten, auch Konstanten- und Variablennamen, bleiben hingegen erhalten. Die Abwicklung des Tests mit dem Hin- und Hersenden der Datenbank war etwas komplizierter als hier erläutert, aber jedenfalls erhielt Wayne Phillips meine Test-MDE und retournierte sie nach ungefähr 40 Minuten in Form einer wiederhergestellten MDB an den Mittelsmann.
Die Qualität seiner Arbeit war verblüffend. Dass die Formulare und Berichte komplett zugänglich gemacht werden konnten, war zu erwarten.
Abb. 2 zeigt die Entwurfsansicht eines relativ komplexen Beispielformulars mit Kombinationsfeldern, Listenfeldern, Optionsgruppen und so weiter in der zurück gelieferten MDB. Dass jedoch der komplette Code der Datenbank in so gutem Zustand zurückkam, hat mich doch etwas überrascht.
Keine Funktionseinbußen durch
Reverse Engineering
Der Code war voll funktionsfähig, auch in den kompliziertesten Konstruktionen und API-Aufrufen. Nur an einigen Stellen war der Code gegenüber dem ursprünglichen Quellcode leicht verändert. Diese Änderungen hatten aber keine Auswirkungen auf seine Funktionalität:
Abb. 2: Entwurfsansicht in der Ergebnis-MDB
Die Kommentare konnten wie erwartet nicht wiederhergestellt werden.
Konstantenmaskierungen waren durch die Werte ersetzt, zum Beispiel vbTextCompare durch 1 oder dbOpenSnapshot durch 4.
Die Namen der Sprungmarken zur Fehlerbehandlung waren durch andere Standards ersetzt.
Manche Schleifen und Entscheidungsstrukturen wurden zum Teil durch praktisch gleichwertige ausgetauscht - etwa Do Loop durch While Wend oder Select Case durch If Then.
With-Konstrukte wurden weggelassen.
Das folgende Beispiel zeigt, wie ich With zum Ansprechen von Feldern und Methoden eines Recordsets verwendete:
With rs
.AddNew
!Lan_Id = lngLan
!Voo_Object = strObjName
.Update
End With
In der rekonstruierten MDB-Datei hingegen wurde das kaum bekannte und im Objektkatalog versteckte Collect zum Ansprechen der Felder verwendet:
rs.AddNew
rs.Collect("Lan_Id") = lngLan
rs.Collect("Voo_Object") = strObjName
rs.Update 1, 0
Unbekannte Parameter?
Bemerkenswert ist die letzte Zeile des Beispielcodes. Kaum jemand verwendet die optionalen Parameter der DAO-Update-Methode für Typ und Wirkung des Updates, die hier mit den Werten 1 und 0 belegt sind. In der zurück gelieferten MDB sind alle optionalen Parameter belegt und alles ist explizit ausgeschrieben, was wahrscheinlich schon beim Kompilieren durch Access selber passiert.
Schöner Code durch Reverse Engineering
Es werden generell keine Standardeigenschaften und -parameter genutzt, sondern - im Gegensatz zu meinem ursprünglichen Code - Value, ByRef und Co. immer explizit verwendet. Ich muss zugeben, dass der zurückverwandelte Code in manchen Bereichen durch diesen expliziten Stil "schöner" und einfacher zu lesen ist als das Original.
Wie das Reverse Engineering technisch funktioniert, blieb natürlich Betriebsgeheimnis von iTech Masters. Das prompte Zurücksenden lässt vermuten, dass man sich dort ein Tool dafür gebastelt hat.
Die Firma bietet auch einen Reparaturservice für sämtliche Objekte einer Datenbank an, den vor kurzem ein befreundeter Kollege in einem schwierigen Fall mit defekten Formularen in Anspruch genommen hat.
Das Resultat kam innerhalb weniger Minuten automatisiert per Mail zurück und war ebenfalls tadellos. Bei iTech Masters muss also jemand hervorragende Kenntnisse über die Struktur der Access-Datenbankdateien besitzen und sich viel Arbeit bei deren Entschlüsselung und dann beim Herstellen entsprechender Tools gemacht haben.
Fazit
Mit der "absoluten" Sicherheit für den Programmcode durch MDEs ist es vorbei. iTech Masters verlangt laut seiner Webseite eindeutige Beweise dafür, dass man Eigentümer der MDE ist, bevor man den Reverse Engineering Service in Anspruch nehmen kann. Es ist im Sinne vieler Access-Entwickler, die MDEs als Schutz verwenden, zu hoffen, dass das seriös gehandhabt wird, und dass das technische Know-how sich nicht weiter verbreitet.
Was die anderen Teile des Access-Sicherheitssystems betrifft, so hat Microsoft in der neuen Version Access 2007 die Konsequenz aus den lange bekannten Schwächen gezogen und das klassische Sicherheitssystem für Datenbanken im neuen Format (ACCDB) schlicht entfernt.
Nur für MDBs, also alte Access-Formate, sollen aus Kompatibilitätsgründen auch in Access 2007 noch die bisherigen MDWs funktionieren.
Das Datenbankkennwort hingegen ist etwas verbessert ebenso weiter vorhanden wie die Möglichkeit zur Umwandlung in MDEs.
Microsoft behauptet sogar, es habe immer auf die Unsicherheit des Access-Sicherheitssystems hingewiesen und bei hohen Sicherheitsbedürfnissen den Umstieg auf den SQL Server empfohlen. Nun, ich habe das ein wenig anders in Erinnerung, habe aber persönlich kein Problem mit dieser Entscheidung.
Ich sage meinen Kunden seit jeher offen, dass Daten und Objekte in Access nicht besonders gut abzusichern sind und rate von der Verwendung des Sicherheitssystems ab - nicht nur wegen der Knackbarkeit, sondern auch wegen der oft schlechteren Performance im Netzbetrieb bei aktiviertem Sicherheitssystem.
Für die meisten meiner Kunden ist das aus betrieblichen Gründen kein Problem. Bei manchen Anwendungen verwende ich zur Absicherung eine Kombinationen aus allem, was die Startoptionen bieten, zudem Abschalten der Umschalttaste, Datenbankkennwort auf das Backend und selbst verwalteten Berechtigungssystemen, meist verbunden mit dem Auslesen des Windows-Anmeldenamens.
Das ist natürlich für versierte Access-Entwickler einfach zu umgehen, reicht aber, um technisch unbedarfte Neugierige abzuhalten und User vor sich selbst zu schützen, indem man ihnen manche Bereiche der Anwendung gar nicht zu sehen gibt.
Das ist in etwa auch der Weg, den Microsoft für Access 2007 empfiehlt. Es hat nur etwas länger gebraucht für den offeneren Umgang mit diesem Thema in Redmond.
| 
