![[Chaos CD]](../../images/chaoscd.jpg) |
| ![[Gescannte Version]](../../images/scan.jpg) |
![[ -- ]](../../images/prev.jpg) |
![[ ++ ]](../../images/next.jpg) |
![[Suchen]](../../images/search.jpg) |
|
| |
|
|
|
Im Fadenkreuz: SAP R / 3Einer unser Autoren hatte vor einigen Monaten das Glück (oder sagen wir angesichts des geringen Unterhaltungsfaktors besser: die Gelegenheit) eine Administrator-Schulung für SAP R/3 zu besuchen. Untenstehend geben wir seine Notizen, subjektiven Anmerkungen und persönlichen Bemerkungen wieder, damit der geneigte Leser einen ersten Eindruck von den Zuständen in einem System bekommt, mit dem 80% der Buchhaltung der deutschen Wirtschaft betrieben wird. Konzeptionelle Features von R/3:
Für eine Security-Prüfung von R/3 muß man sich natürlich zuerst fragen, welches Ziel ein Angriff haben könnte. Bei R/3 ist die Angriffsfläche natürlich besonders hoch, weil R/3 potentiell sehr sensible Daten beinhaltet, wie z.B. Gehälter, Rechnungen, Lagerbestände, Produktionszahlen oder Personaldaten. Wir definieren also als höchstes Ziel für einen Angreifer den Zugriff auf R/3-Tabellen. Besondere Beachtung verdient hierbei der Umstand, daß mehr als 80% aller Angriffe auf Computersysteme von sogenannten Innentätern, also frustrierten oder abgeworbenen Mitarbeitern begangen werden. Das erste Thema ist also das Berechtigungs-konzept von R/3. Da bei R/3 die Daten nicht direkt im Filesystem abgelegt sind, sondern in Datenbank-Tabellen, übernimmt die User-Überprüfung nicht das Betriebssystem. Das ist einerseits erfreulich, weil man dann auf OS-Ebene den R/3-Usern keine Accounts einrichten muß. Andererseits ist das bedenklich, weil auf Betriebssystem-Ebene die Zugriffssicherung ein gut verstandenes Problem ist. Die offensichtliche Alternative für die Rechte-Prüfung wäre, auf Datenbank-Ebene den Zugriff zu regulieren. Die SAP entschied sich aber dafür, die Zugriffsberechtigungen komplett selber zu implementieren. Auf Nachfrage wurde als Begründung genannt, daß die Datenbanken das alle unterschiedlich machten und man ja portabel bleiben wolle. Seltsam, wo es doch sowieso für jedes Datenbank-Backend eigenen Code gibt. An dieser Stelle freut sich der Sicherheits-Fachmann, daß bei R/3 die ABAP-Quellen mitgeliefert werden. Man kann sich also anschauen, wie die Berechtigungen implementiert werden. Und ein erster Blick sieht vielversprechend aus, hat sich die SAP doch entschieden, die Rechte rein kumulativ zu vergeben, d.h. was nicht explizit erlaubt wurde, ist verboten. Leider stellt sich heraus, daß die Rechte nicht pro Datenbank-Objekt vergeben werden, sondern die ABAP-Programme "von Hand" (und nur von Hand!) die Berechtigungen prüfen. Wünschens-wert wäre gewesen, einem User den Lesezugriff auf die Gehalts-Tabelle zu verweigern, und dann sicher zu sein, daß er keinen Zugriff hat. Bei R/3 muß man alle zugreifenden Programme daraufhin untersuchen, ob sie dem User Zugriffe ermöglichen, die er nicht haben dürfte. Bei einem Tabellenumfang von über 50 MB bei den ABAP-Quellen ist das sicher keine triviale Aufgabe. Schlimmer noch: das eherne Prinzip der Sicherheit ist so verletzt, das Prinzip der minimalen Berechtigung! Es ist nicht möglich, einem Developer Zugriff nur auf seinen Bereich einzuräumen. Wenn eine Firma jetzt einen Consultant einstellt, der für sie ein ABAP-Programm schreibt, und der Mann fühlt sich schlecht behandelt, kann er in seinem kleinen Buchungs-Programm auch vollen Zugriff auf die User- und Payroll-Tabellen nehmen oder gar das ganze System zum Stillstand bringen. Wünschenswert wäre ein zweistufiges Sicherheitsmodell, wo für jedes Programm genau wie für jeden User explizit der Zugriff erlaubt werden muß. Der einzige Schutz gegen maliziöse Programme ist die sogenannte System-Landschaft. Eine R/3-Installation besteht gewöhnlich aus mehreren Systemen. SAP empfiehlt drei Systeme: ein Development-System, ein Quality-Assurance-System und ein Production-System. Die Idee ist, daß der Developer mit seinem Programm nur auf dem Development-System spielen darf, und das Programm dann nur vom Administrator zum jeweils nächsten System transportiert werden kann. Das mag zwar gegen versehentlichen Datenausfall helfen, aber gegen Datums- oder System-ID-Trigger ist so kein Kraut gewachsen. Halten wir also fest: jeder Entwickler kann eine R/3-Installation kompromittieren. Prinzipiell kann der Administrator natürlich alle entwickelten Programme nach offensichtlichen trojanischen Code-Fetzen absuchen, aber das ist nicht zumutbar und auch keine prinzipielle Lösung für das Problem. Um die Tragweite dieses Problems zu begreifen, muß man einen Blick in den Stellenmarkt einer fast beliebigen IT-Publikation werfen und mit Erstaunen feststellen, daß praktisch alle Firmen händeringend R/3-Experten suchen. Der Markt konnte dem explosiven Wachstum der SAP nicht folgen. Es wäre also ein leichtes für eine Firma (oder einen Nachrichtendienst), der Konkurrenz einen SAP-Consultant unterzuschieben, mit dem Ziel, Intelligence zu sammeln oder einen Bankrott zu erzeugen (Backups werden sicher nicht ewig aufgehoben und ein trojanisches Pferd mit Datumssteuerung muß nur den Backup-Zyklus überleben, um auf allen Backups vorhanden zu sein). Wenn man jetzt bedenkt, daß praktisch alle größeren Unternehmen R/3 einsetzen, ist die strategische Bedeutung einer R/3-Kompromittierung für einen Nachrichtendienst offensichtlich. Das Problem liegt aber noch tiefer. Wie oben bereits angedeutet, liegen alle ABAP-Quellen in einer Datenbank. Ein direktes Editieren scheidet also aus. Bei R/3 werden ABAP-Quellen mit dem SAPGUI in einer R/3-Transaktion editiert, ähnlich wie man die User-Tabelle bearbeiten würde. Diese Workbench-Transaktion ist genau wie die anderen Transaktionen selber in ABAP geschrieben. Dieser Umstand ermöglicht eine Attacke, gegen die praktisch kein Kraut gewachsen ist. Es ist nämlich denkbar, den ABAP-Quellcode der Workbench-Transaktion so zu ändern, daß es maliziösen Code nicht anzeigt, inklusive dieser Änderung an sich selber natürlich. Das Ergebnis wäre ein R/3-System, das genau aussieht wie immer, und sogar eine Analyse der ABAP-Quellcodes zeigt ein unverändertes System. Tatsächlich könnten im Hintergrund aber praktisch beliebige Datenbank-Modifikationen laufen. Das klingt möglicherweise nicht oder nur unter gewaltigem Aufwand umsetzbar. Die Geschichte zeigt aber einen ähnlichen (sogar komplizierteren Fall), bei dem nicht mal materielle Gesichtspunkte der Hintergrund waren, nämlich ein C-Compiler, der erkannte, wenn er das Login-Programm übersetzte, und dort einen weiteren Root-Zugang einbaute, aber auch eine Über-setzung von sich selber erkannte und diesen Code wieder einbaute in das Kompilat, so daß alle Quellcodes "sauber" waren. Wenn man bedenkt, um welche Geldmengen es geht, wenn man einen Angriff wie diesen gegen die deutschen Großbanken oder Automobil-Hersteller richten würde (der Angriff müßte nur einmal entwickelt werden und wäre sofort weltweit einsetzbar!), wird einem das Ausmaß der Problematik bewußt. Weil auch innerhalb von SAP mit der Workbench gearbeitet wird, würden auch die SAP-Entwickler von so einem trojanischen Pferd nichts mitbekommen, und es ab dem nächsten Update mit ausliefern. Daß das nicht schon längst geschehen ist, kann in meinen Augen auch niemand wirklich ausschließen. Vielleicht als Anmerkung am Rande: R/3 übersetzt die ABAP-Quellen in einen Zwischencode, der natürlich auch in einer SQL-Tabelle gespeichert wird. Es würde also wahrscheinlich reichen, diesen kompilierten Zwischencode in der Tabelle zu modifizieren, um den gewünschten Effekt zu haben. Nach diesen allgemeinen Überlegungen noch ein paar konkrete Betrachtungen: Ein Interpreter-Kernel ist ein sehr gutes Konzept. Er kann ganze Fehlerklassen ausschließen, wie Pufferüberläufe und Memory-Leaks. Aber ein Interpreter macht das Gesamtprogramm nur vertrauenswürdiger, wenn er klein und überschaubar ist. Der R/3-"Kernel" ist über 11 Megabytes groß (das ist bereits das gestrippte Binary!). Insgesamt heißt Security auch Schutz gegen Denial-Of-Service-Attacken, d. h. es darf nicht möglich sein, ein System durch einen Bug zum Komplett-Absturz zu bringen. Bekanntermaßen steigt die Wahrscheinlichkeit für die Existenz eines Bugs exponentiell mit der Programmgröße. Bei einem 11-MB-Kernel und 50 MB ABAP-Quellen kann von Überschaubarkeit bei R/3 keine Rede sein. Die Software-Industrie hat sich in den letzten Jahrzehnten Konzepte überlegt, um ein Projekt überschaubar und wartbar zu halten. An erster Stelle steht, daß der Code kommentiert sein muß und daß Bezeichner aussagekräftig vergeben werden. Bei R/3 scheinen Bezeichner auf 10 Zeichen beschränkt zu sein, so daß Bezeichner grundsätzlich Namen wie Line Noise haben. Ähnlich sieht es bei den Namen von Tabellen und Tablespaces aus. So erkennt man den R/3-Newbie daran, daß er noch nicht weiß, wofür PSAPBTABD steht. (Das ist der Datenteil (im Gegensatz zum Index-Teil, der PSAPBTABI heißt) der Bewegungsdaten-Tabelle (d.h. Buchungen). Der Wartbarkeit ist das natürlich extrem abträglich. Hinzu kommt, daß innerhalb von R/3 sehr oft Code dupliziert wird, der von anderen (gewöhnlich besser) erledigt wird. U. a. handelt es sich um:
Schließlich sorgen bei R/3 noch Details für einen bitteren Nachgeschmack wie die Limitierung von Passwörtern auf 8 Zeichen, wobei Groß- und Kleinschreibung egal ist. Die Erfahrung sagt außerdem, daß SAP-Installationen gewöhnlich von Nicht-Profis gemacht werden. Meistens wird für die Installation und das Customizing ein Consultant eingestellt, der danach aber weg ist. Und R/3-Profis haben selten gleichzeitig ein tieferes Verständnis für das zugrundeliegende Betriebssystem. So ist in praktisch allen Fällen auf den R/3-Servern noch jeder Standard-Dienst des Betriebssystems und der Datenbank aktiviert, ja telnet und ftp werden sogar ständig noch benutzt (telnet zur Fernwartung und ftp weil die eingebauten Methoden zur Dateiübertragung zu langsam sind). Schlimmer noch - SAP setzt eine NFS-Installation zwischen den Systemen voraus! Aber auch alte Bekannte wie rexec werden von R/3 benutzt. Wem diese Probleme noch nicht reichen: die eigentlichen Transaktionen zwischen R/3 und dem SAPGUI werden nicht verschlüsselt. Sie gehen zwar nicht im Klartext über das Netz, weil sie komprimiert sind, aber von Sicherheit kann auch hier nicht die Rede sein. Wenigstens stehen die Passwörter nicht im Klartext in der DatenbankŠ Sozusagen als Salz in der Suppe bietet SAP jetzt auch einen Internet Transaction Server an, der den Web-Server mit dem Warenwirtschafts- System verbinden soll. Dieser Server wird nur für NT angeboten. Um es auf den Punkt zu bringen: R/3 ist unsicher. Betriebssysteme sind meistens auch unsicher. Sobald jemand Shell-Zugriff auf einem System hat, hat er gewöhnlich auch schnell Zugriff auf die Oracle-Datenbank, und damit hat er Total-Zugriff auf die R/3-Datenbasis. In diesem Moment hat der Systembetreiber verloren. Andersherum kann ein Developer in einem R/3-System die Datenbank komplett ändern und auch beliebige Shell-Kommandos ausführen, d. h. sich eine Shell erzeugen. Neben den üblichen netzwerkbezogenen Sicherheitsmaßnahmen bleibt also für den Systembetreiber eigentlich nur:
Die Account-Daten in einer SAP R/3-Standardinstallation sind:
SYS CHANGE_ON_INSTALL SYSTEM MANAGER SAPR3 SAP
User Passwort DDIC 19920706 SAP* 06071992 (6.7.1992 war das Datum der ersten R/3 Produktiv-Installation)
anonymous@some.where
|
[Datenschleuder]
[62]
Im Fadenkreuz: SAP R / 3