|
In den Beiträgen werden einige Schutzmethoden vorgestellt die auf VBA-Code basieren. Diese Methoden bieten natürlich nur einen effektiven Schutz, wenn man den VBA- Code vor neugierigen Blicken schützen kann. Hierzu bietet Excel zwar die VBA-Passwort Option jedoch lässt sich dieser Schutz sehr leicht umgehen. In einer mittels Excel 2003 erstellten Datei lässt sich z.B. das VBA-Passwort durch simples patchen des "DPB" Strings umgehen, weiteres zum Thema DPB-Patch kann hier nachgelesen werden. Darüber hinaus gibt es zahlreiche kommerzielle Systeme die auf Knopfdruck den Schutz entfernen können. Diese Systeme basieren unter anderem auf der "DPB"-Patch Technik oder der sogenannten VBA-Hintertürtechnik. Unter der Hintertürtechnik ist zu verstehen, dass während der Ausführung der Excel-Datei die VBE.DLL so verändert wird, dass jedes VBA-Passwort als gültig anerkannt wird.
Nun ist es aber nicht so, dass man sich dagegen nicht wehren kann :-) Eine Lösung wäre z.B. man wandelt seine XLS-Datei in eine EXE-Datei um. Aufgrund der Umwandlung erfolgt bei vielen Konvertierungssystemen eine Komprimierung/Verschlüsselung, dies schützt vor dem "DPB"-Patch oder generell vor dem generischen Passwort-Patchen, da die Daten beim Durchsuchen der Datei nicht mehr gefunden werden. Das Konvertieren bietet auch Schutz gegen die VBE.DLL Manipulation, denn bei allen kommerziellen Systemen erfolgt das Manipulieren in Form eines Prozess bezogenen DLL-Hooks. Durch das Konvertieren erfolgt das Ausführen der Excel-Datei in einem neuen Prozess, der nicht mehr unter der Kontrolle des Hook-Programmes steht. Somit hat das Manipulieren keine Auswirkung.
Neben der reinen XLS->EXE Konvertierung gibt es natürlich noch VBA-Schutzsysteme welche zusätzlich noch zahlreiche Schutzoptionen bieten.
XLS->EXE Programme:
- DoneEx XCell Compiler - Kommerzielles System, bietet neben der Konvertierung noch zahlreiche Schutzoptionen (z.B. Formel- und VBA-Schutz)
- LockXLS - Kommerzielles System, bietet zahlreiche Schutzoptionen (z.B. Formel- und VBA-Schutz)
- http://cpap.com.br/orlando/#XLtoExe - Freeware Konvertierungs-Tool.
|
|
22.06.2008 20:20 |
|
dogfight
Jungspund
Dabei seit: 13.09.2008
Beiträge: 11
|
|
Eine weitere VBA-Schutzmöglichkeit wäre den VBA-Code in eine DLL oder COM-Addin auszulagern, dadurch ist der Code nicht mehr in der Exceldatei selbst.
Eine sehr ausführliche Anleitung zum Thema COM-Addin findet man unter:
http://www.donkarl.com/AEK/AEKDownloads/AEK5_AddIns.zip
Wer denkt mit den Excel-Bordeigenen Schutzmöglichkeit einen vernünftigen Schutz erzielen zu können dem sei gesagt, das wird nicht funzen. Im Nachfolgenden möchte ich ein paar Sicherheitslücken vorstellen:
Blattschutz:
Der Blattschutz bietet die Möglichkeit Formeln zu verbergen oder Zellen vor Veränderungen zu schützen. Hierzu wird ein Passwort vergeben, welches intern 16bit gross ist. Umgehen lässt sich der Schutz folgendermaßen:
1) Mittels OpenOffice. Geschützter Bereich in Excel markieren und per Copy&Paste in OpenOffice einfügen, OpenOffice ignoriert bei dieser Art den Blattschutz.
2) Aufgrund der internen Schlüssellänge von nur 16bit lässt sich ein gültiges Passwort sehr schnell mittels BruteForce bestimmen. Hierzu stehen im Internet einige Makros zur Verfügung, einfach mal nach "Blattschutz löschen" googeln.
Wie genau die Blattschutz-Passwortverschlüsselung funktioniert kann hier nachgelesen werden, nachfolgend der entsprechende Auszug:
Zitat: |
Info für Profis:
Die Blattschutz-Verschlüsselung von Excel 2000 und XP ist relativ simpel. Jedem Zeichen des Passworts entspricht ein achtstelliger Binärwert (8 Bit). Dieser wird für die Verschlüsselung um seine Position im Passwort Bit-weise nach links verschoben (Left-Shift). Das Verschieben einer binären Zahl um ein Bit nach links entspricht im dezimalen Raum einer Multiplikation mit 2. Beim ersten Zeichen wird der Wert also um ein Bit verschoben, die Binärzahl verlängert sich auf neun Stellen. Beim zweiten Zeichen verschiebt sich der Wert um zwei Bit, die Binärzahl erweitert sich so auf zehn Stellen und so weiter.
Da die Länge der Binärzahl bei Excel auf 16 Bit begrenzt ist, erfolgt bei Kennwörtern, die länger als acht Zeichen sind, ab dem neunten Zeichen zusätzlich zum Left-Shift eine Bit-Rotation um die jeweils überzähligen Stellen. Somit verkürzt sich der binäre String immer um eine Stelle und bleibt ab dem neunten Zeichen 16-stellig. Alle einzelnen Werte, der Binärwert der Kennwortlänge und die hexadezimale Konstante 0xCE4B werden dann über "exklusives Oder“ (XOR) miteinander verknüpft. Daraus errechnet sich der Wert, der in der Tabellendatei gespeichert wird.
Eine Binärzahl mit 16 Stellen (16 Bit) liefert maximal zwei hoch sechzehn unterschiedliche Hash-Werte, also insgesamt "nur“ 65.536 Möglichkeiten. Aufgrund dieser Begrenzung kann nicht jedes mögliche Kennwort einen eindeutigen Hash-Wert erhalten. Genau diese Tatsache nutzt das Makro aus und findet in einem kleineren Werteraum immer ein alternatives Kennwort, über das sich der Schutz des Arbeitsblatts deaktivieren lässt.
|
|
3) Patch des Passwortvergleichs in der Excel-Anwendung (Excel.exe), somit wird jedes Passwort als gültig anerkannt.
4) Und in Excel2007 hat Microsoft das Ganze sogar noch getoppt. Aufgrund des neuen Excel-Formats .xlsx/.xlsm (verkappte Zip-Datei und XML basierend) sind Formeln und Blattschutz für jeden leicht ersichtlich. Nachfolgend ein XML-Auszug:
code: |
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
- <worksheet xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships">
<dimension ref="E6:G8" />
- <sheetViews>
- <sheetView tabSelected="1" workbookViewId="0">
<selection activeCell="G8" sqref="G8" />
</sheetView>
</sheetViews>
<sheetFormatPr baseColWidth="10" defaultRowHeight="15" />
- <sheetData>
- <row r="6" spans="5:7">
- <c r="E6" t="s">
<v>0</v>
</c>
</row>
- <row r="7" spans="5:7">
- <c r="E7" t="s">
<v>1</v>
</c>
</row>
- <row r="8" spans="5:7">
- <c r="E8">
<v>12</v>
</c>
- <c r="F8">
<v>25</v>
</c>
- <c r="G8" s="1">
<f>E8+F8</f>
<v>37</v>
</c>
</row>
</sheetData>
<sheetProtection password="CBEB" sheet="1" objects="1" scenarios="1" />
<pageMargins left="0.7" right="0.7" top="0.78740157499999996" bottom="0.78740157499999996" header="0.3" footer="0.3" />
<pageSetup paperSize="9" orientation="portrait" r:id="rId1" />
</worksheet>
|
|
Man beachte den Eintrag "sheet Protection", dabei handelt es sich um die Blattschutz Aktivierung, gefolgt von dem 16bit Password (High/Low Byte). Weiter beachte man auch den Eintrag <f>E8+F8</f>, Formeln werden in dem neuen Excel-Format im Klartext angezeigt, hier Zelle G8 = Zelle E8 + Zelle F8 (37 = 12 + 25).
VBA-Passwort:
Wer seinen VBA-Code vor fremden Blicken schützen möchte, der benutzt die VBA-Passwort Möglichkeit. Hierbei wir wie beim Blattschutz ein Passwort vergeben, welches aber im Gegensatz intern 192bit gross ist. Aufgrund der Schlüssellänge ist die Bruteforce Möglichkeit mal passé. Umgehen lässt sich der Schutz aber wie von Michael schon erwähnt mittels "DPB"-String und VBE.DLL Patch oder noch viel einfacher, einfach mal die geschützte Excel-Datei mittels OpenOffice öffnen und nicht verwundert sein wenn der geschützte VBA-Code zu sehen ist, denn OpenOffice ignoriert das VBA-Passwort.
Fazit:
Wer seine Formeln und VBA-Code einigermaßen sicher schützen möchte, der wird sich mit den Möglichkeiten die Excel von Haus aus mitbringt schwer tun, abhalten werden sie nur einen absoluten Laien. Wer mehr Schutz möchte, der muss ein kommerzielles Schutzsystem einsetzen oder als Alternative im Falle von VBA das Ganze in eine DLL oder COM-Addin auslagern.
Dieser Beitrag wurde schon 1 mal editiert, zum letzten mal von dogfight am 04.10.2008 22:21.
|
|
04.10.2008 22:18 |
|
|
Vor ein paar Tagen bin ich auf folgenden Beitrag gestossen in dem der DoneEx VBA Schutz ein wenig unter die Lupe genommen wurde:
http://www.herber.de/forum/archiv/984to988/t985747.htm
In dem Beitrag wurde gezeigt, dass sich der Schutz z.B. mittels der "thisWorkbook.SaveCopyAs()" Methode und anschliessendem Bruteforce (z.B. mittels des Internetservices www.decryptum.com) auf das Lese/Schreibkennwort umgehen lässt. Die thisWorkbook.SaveCopyAs() Methode bewirkt, dass die geschützte XLS-Datei aus der DoneEx-EXE extrahiert werden kann.
Denke die Test-Datei wurde mit einer älteren Version geschützt. In der neuesten Version funktioniert die Bruteforce-Methode nicht mehr so einfach, denn DoneEx hat das Lese/Schreibkennwort-Verfahren geändert und verwendet jetzt 128bit strong encryption (wird von Microsoft ab Excel 2002 unterstützt) anstelle der einfachen XOR-Verschlüsselung, somit ist der Angriff mittels Bruteforce passe. In dem Beitrag wurde auch das Analysieren des VBA-Codes mit einem Hex-Editor angesprochen, diese Möglichkeit besteht natürlich weiterhin, denn Microsoft verschlüsselt beim Lese/Schreibkennwort Schutz nur die Arbeitsblätter, der VBA-Code bleibt unverschlüsselt (Ausnahme bildet Excel 2007, hier werden Formeln und VBA-Code verschlüsselt). Somit wäre es möglich den VBA-Code zu extrahieren, was aber entsprechendes Know-how voraussetzt. Neben der aufwendigen Extrahierungsmethode existiert jedoch noch eine einfachere Möglichkeit wie sich das Passwort und anschliessend der VBA-Schutz umgehen lässt, somit ist der DoneEx VBA-Schutz nur bedingt zu empfehlen. Erwähnenswert wäre noch, DoneEx aktiviert das strong Encryption Passwort nur in Verbindung mit dem VBA-Schutz, ohne VBA-Schutz lässt sich das extrahierte File ohne Probleme öffnen. Was jedoch nicht möglich ist, ist das Extrahieren der geschützten Formeln, die bleiben weiterhin verborgen und man extrahiert letztendlich nur das Ergebnis.
Was mich natürlich mal neugierig gemacht hat ist, was andere Excel-Schutz Tools mittels der thisWorkbook-Methode so alles preisgeben. Testkandidaten waren:
1) LockXLS V3.8.38 (www.lockxls.de) – bietet Formel- und VBA-Schutz.
2) ExcelSentry V1.4 (www.ExcelSentry.com) – bietet nur Formelschutz.
Bei ExcelSentry blieben die geschützten Formeln auch nach dem Extrahieren weiterhin unzugänglich. Anders verhielt es sich mit LockXLS, hier waren nach dem Extrahieren sowohl die geschützten Formeln wie auch der VBA-Code zugänglich. Funktioniert hat es zwar nicht direkt mit der thisWorkbook-Methode, das wird von LockXls unterbunden, jedoch konnte ich mit einem Programm, das von aussen auf die Excel-Methode Workbooks().SaveCopyAs() zugreift recht leicht den Schutz umgehen.
Somit lautet mein Fazit. Empfehlenswert sind was den Formelschutz anbetrifft DoneEx und ExcelSentry, wobei ich DoneEx als etwas stärker ansehen würde. In beiden Fällen benötigt man aber fundiertes Hacker Know-how, um den Formelschutz umgehen zu können. Der VBA-Schutz von DoneEx bietet meiner Ansicht nach nur Schutz vor dem Hacker-Laien und ist somit nur eingeschränkt zu empfehlen. LockXLS ist derzeitig aufgrund der beschriebenen Schwäche nicht zu empfehlen - Habe den Hersteller (Spreadsheet Tools) über das Sicherheitsproblem informiert und denke in einer der nächsten Versionen ist die Schwäche behoben.
Nachtrag vom 24.11:
Spreadsheet Tools plant noch diese Woche eine neue Version zu releasen.
Nachtrag vom 6.12:
Spreadsheet Tools hat heute eine Version 4.0.0 released in der das Problem behoben wurde. Auf Basis der neuen Version lautet mein Fazit für LockXLS: Im Vergleich zu DoneEx und ExcelSentry würde ich den Formelschutz als schwächer ansehen, dies liegt an der Art und Weise wie LockXLS Formeln schützt (keine explizite Formelverschlüsselung wie bei ExcelSentry oder Code-Konvertierung wie bei DoneEx). Den VBA-Schutz würde ich im Vergleich zu DoneEx als sicherer ansehen und er bietet ausreichend Schutz vor dem erfahrenen Excel und VBA Anwender.
|
|
23.11.2008 15:30 |
|
erty
Jungspund
Dabei seit: 24.07.2009
Beiträge: 10
|
|
|
24.07.2009 18:03 |
|
|