4stelliger PIN-Code an der Tür? Hm, das schaut machbar aus…
via dbasixx.com
Debuggen ohne Admin-Rechte
Für alle Software-Entwickler, die zwar Debuggen können, aber nicht glauben, dass für das Debugging unter Windows unter bestimmten Umständen schon normale Benutzerrechte ausreichen, folgt hier eine kleine Anleitung, wie sie sich selber oder andere von Gegenteil überzeugen können.
Bis vor etlichen Jahren dachte auch ich, dass nur Administratoren debuggen können. Genährt wird die Annahme das durch entsprechende Einträge in den Gruppenpolicies und der Tatsache, dass man zum Entwickeln oftmals Adminrechte benötigt. Tatsächlich benötigt man aber für Anwendungen, die man selber starten kann, die also im eigenen Benutzerkontext ausgeführt werden, keine Admin-Rechte. Das birgt erhebliche Sicherheitsrisiken für Fat-Client-Anwendungen, die von einer Anzahl an Mitarbeitern auf deren Rechnern ausgeführt werden.
Normale Mitarbeiter können freilich eher keine Debugger bedienen. Tracer verwenden aber teilweise ähnliche Mechanismen, um Anwendungen viel bequemer auszuforschen. Sie sind leichter zu bedienen und die Ergebnisse einfacher weiter zu verwenden. Wo man debuggen kann, da kann man auch tracen, umgekehrt nicht unbedingt.
Die folgenden Anleitung ist recht spartanisch, sollte aber für alle Softwareentwickler ausreichend sein, um es selber auszuprobieren. Das Debuggen an sich wird nicht erklärt, weil das die Zielgruppe des Artikels schon kennt. Daher plaudert die Anleitung in meinen Augen nichts Sicherheitskritisches aus. Genau genommen ist sie sogar äußerst trivial. Sie soll auch nur dazu motivieren eigene Annahmen zu überprüfen, wenn es nötig ist.
Wenn also wieder mal jemand sagt, dass für Debuggng und Tracing Administratorrechte nötig sind, dann fragt ihn mal, ob er das ausprobiert hat…
Vorbereitung
Die Schritte habe ich unter Windows 7 Professional ausgeführt. Die Transferleistung auf andere Versionen ist aber gering.
Benutzer ohne Adminrechte anlegen:
- "cmd.exe" als Administrator ausführen.
- Dort ausführen: net user /add noadminuser topsecrpwd
- Mit "net user noadminuser" kann man prüfen, dass er wirklich nur Mitglied der Gruppe "Benutzer ist.
Debugger besorgen:
- Hier nehmen wir den vergleichsweise beliebten Debugger "Ollydbg". Ich kenne und nutze ihn sonst nicht und habe ihn vor allem deswegen ausgewählt, weil er keine Installation benötigt. Das darf ein normaler Benutzer nämlich nicht.
- Wir könnten den auch im kommenden Schritt download, wenn wir uns als Benutzer "noadminuser" anmelden. Aber der erste Start des Browsers dauert immer so lange, weil er Profile einrichtet, etc…
Durchführung
Dazu melden wir uns als der Windows-Benutzer "noadminuser" an, entpacken das Archiv mit Ollydbg irgendwohin, z.B, auf den Desktop. Mit einem Doppelklick auf Ollydbg.exe wird der Debugger gestartet.
Prompt werden wir mit dem Hinweis begrüßt, dass wir keine Admin-Rechte haben und daher einige Aktionen nicht möglich sind:
Das stört uns aber weiter nicht, wir wollen weder Remote-Debugging, noch andere fortgeschrittene Dinge tun.
Anschließend starten wir über "File | Open" die zu überwachende Anwendung "notepad.exe" aus dem Verzeichnis "C:\windows\system32". Daraufhin springt der Debugger in die Startsequenz der Anwendung. Mit einen Klick auf den Run-Button kommen wir in die eigentliche Anwendung und können debuggen:
Freilich kann man auch auf andere Arten debuggen, das ist nur ein Beispiel wie ich es machen würde. Hier kann jeder selber die Möglichkeiten ausprobieren. Der Proof-of-Concept ist damit abgeschlossen. Tests mit verschiedenen erhältlichen Tracern kann jeder Interessierte selber machen.
Aufräumen nicht vergessen
Wer dazu keine VM genutzt hat, der muss den Benutzer "noadminuser" auch wieder löschen. Das ist diesmal besser über die Systemsteuerung zu erledigen, weil dann alle Profil-Dateien mitgelöscht werden können.
Umgang mit der Meldung von Sicherheitslücken
Auch in unserer Firma ist niemand erfreut, wenn eine Sicherheitslücke von Außen gemeldet wird. Dann geht bei uns nämlich richtig die Post ab: Alarmstufe rot, Test, Reproduktion, Beseitigung und ein neues Release, dass die Lücke stopft. Also jede Menge Stress. Besser ist es, wenn wir die Lücken selber finden, dennoch ist es am zweitbesten, wenn wir die Probleme mitgeteilt bekommen. Am schlimmsten wäre es, wenn die Lücke ohne vorherigen Hinweis an uns anderen mitgeteilt würde.
Daher hat der Umgang mit den Findern entsprechend zuvorkommend zu sein: Dialog, Prüfung, Dank und Information, wann das Release mit der Beseitigung kommt. Dann kann man die Veröffentlichung mit dem Finder koordinieren. Ob das immer so gelingt, kann ich nicht beurteilen. Der Wille ist jedenfalls da.
Wegen des entstehenden Aufwandes kann ich schon verstehen, wenn jemand nicht gerade erfreut darüber ist, wenn ihm ein Problem gemeldet wird. Leider scheinen aber auch noch ganz andere Reaktionen üblich zu sein:
- Leugnen/Verdrängen: Das ist kein Problem. Wir haben alles im Griff. So einen Angriff sind utopische Voraussetzungen nötig.
- Kleinreden: Es gab noch nie eine Angriff, der die Lücke ausnutzt. Das ist nur eine theoretische Lücke. Alles halb so wild.
- Kriminalisieren: Wer so eine Lücke findet, muss ein Krimineller sein. Er verhält sich nicht konform. "Wehe Dir, oh, Finder der Lücke."
Der Anlass meines Schreibens ist der Umgang mit dem Studenten Hamed Al-Khabaz: er wurde der Hochschule verwiesen. Die Hochschule widerspricht zwar der Version des Studenten, aber unstrittig ist wohl, dass er eine Sicherheitslücke fand, sie meldete und ein paar Tage nach der Rückmeldung die Lücke werde behoben, mal nachschaute, ob das auch wirklich durchgeführt wurde. Was für eine Lücke das ist, ist nicht von Belang. Es ist nur wichtig, dass es um die personenbezogenen Daten aller Studenten ging: also die schlimmste anzunehmende Sicherheitslücke einer Universität.
Leider hat die Hochschule hier den nötigen Mentatiltätswandel noch nicht vollzogen: Den Melder eines Sicherheitsproblems zu kriminalisieren, weil er weiterhin nach Lücken suchte, wirft ein sehr schlechtes Licht auf die Hochschule. Anstatt ihm dankbar zu sein und ihn auch offiziell damit zu beauftragen, dass er die eigenen Systeme testet und Probleme meldet, wird verletzt reagiert. Da er so großes Interesse an dem Thema hat, hätte er es möglicherweise sogar im Rahmen eines Seminars (also kostenlos) gemacht. Eine Win-Win-Situation: der Student hat ein interessantes Seminar mit einer vermutlich guten Note und die Hochschule einen kostenlosen Penetrationstest für das wichtigste System.
Ich finde es ein Zeichen von fehlendem Problembewusstsein, wenn offizielle Stellen oder Firmen mit Sicherheitsproblemen und der Meldung von Lücken nicht professionell umgehen. Ob es nun daran liegt, dass manche Menschen keine Fehler zugeben können, sich einfach nur belästigt fühlen, sich rächen wollen oder andere Gründe haben, wird man wohl nie erfahren. Zum Glück werden solche deplatzierten Reaktionen heute manchmal bekannt.
Ich kenne die Hintergründe nicht, aber von ganz weit weg gesehen, setzt sich die Universität in ein sehr unprofessionelles Licht. Dem Studenten hilft das wohl nicht: seine Laufbahn ist ruiniert, wenn es ihm nicht gelingt, das Kollege zum Einlenken zu bewegen. Er wurde kriminalisiert, sein Stipendium ist weg und sein Studienplatz ebenso. Es klingt so als würde ein Exempel statuiert. Armer Kerl.
Details zum aktuellen Stand bei Heise.de: Geschasster Campus-Hacker: College widerspricht
Wie kritisch ist es, wenn eine Anwendung mit dem SA arbeitet?
Im Zusammenhang mit meinem Posting "JTL-Wawi und das veröffentlichte SA-Passwort" stellte Ralph die Frage, wie kritisch es ist, wenn ich eine Anwendung nutze, die immer mit dem Sysadmin arbeitet. In dem Posting habe ich schon beschrieben, warum es für einen Angreifer ein so großes Geschenk ist an das SA-Passwort zu kommen. Kurz gesagt, er kann sich damit bislang meistens zum Administrator am Server machen.
Im konkreten Fall kann zunächst jeder Depp einen Angriff durchführen solange das im Internet veröffentlichte Default-Passwort nicht geändert wird. Gehen wir also mal davon aus, ein Admin ändert das SA-Passwort. Wie gefährdet bin ich dann als Nutzer so einer Software?
Wenn man einschätzen will, wie kritisch eine Lücke ist, dann muss man zwei Fragen beantworten:
- Wie schlimm ist es, wenn jemand die Lücke ausnutzt?
- Wie schwierig ist es, die Lücke auszunutzen?
Wie lauten die Antworten in diesem konkreten Fall, wenn die Software als Prozess am Arbeitsplatz ausgeführt wird?
Wie schlimm ist es, wenn jemand die Lücke ausnutzt?
Worst Case! Weil der SQL-Server-Dienst im Systemkontext läuft, ist der Server kompromittiert oder der Einzelarbeitsplatz kann komplett aus der Ferne übernommen werden, ja nachdem wo der SQL Server installiert wurde. Nichts ist mehr sicher, dem Angreifer ist nichts unmöglich.
Wie schwierig ist es, die Lücke auszunutzen?
Es sind mehrere Lücken, die beide damit zu tun haben, dass die Anwendung am Arbeitsplatz ausgeführt wird und damit im Kontext des Benutzers:
- Das SA-Passwort wird beim Einrichten an eine Stelle geschrieben, die jeder Benutzer lesen kann. Die verwendete Verschlüsselungsmethoden sind leicht protokollierbar, der Schlüssel ist ebenso zugänglich. Das ist für einen ernsthaften Angreifer die einfachste Methode: Die Software bei sich installieren, in aller Ruhe ausspähen und einen Exploit schreiben, der anderen zur Verfügung gestellt werden kann.
- Während des Zugriffs kann jeder Prozess, der im gleichen Benutzerkontext läuft wie das JTL-WAWI, den JTL-WAWI-Prozess ausspähen: er kann den Hauptspeicher durchwühlen, die von der Anwendung verwendeten Schnittstellen sniffen oder sich sogar als Debugger an den Prozess hängen. Wenigstens seit Windows-XP hat jeder Windows-Benutzer das Recht die "eigenen" Prozesse derart zu untersuchen. Viele Entwickler glauben offenbar dazu wären Admin-Rechte nötig. Daher habe ich beschlossen für diese Zielgruppe ein Buch zur Sicherheit von Anwendungen mit SQL-Server zu schreiben. Mal schauen, ob es auf Interesse stößt.
Als Angreifer haben wir also zwei Angriffspunkte, um an das begehrte SA-Kennwort zu bekommen. Wie man das ganz konkret macht, beschreibe ich hier absichtlich nicht. Angehende Skript-Kids möchte ich nicht zu unüberlegten (weil kriminellen) Handlungen verleiten. Aber seien Sie sicher, dass die bösen Jungs wissen wie das funktioniert. Jeder Fachinformatiker im ersten Lehrjahr sollte dazu in der Lage sein. Ebenso reichen die im Informatikunterricht vermittelten Kenntnisse, um sich da einzulesen.
Es ist nur die Frage, ob Angreifer sich die Mühe machen. Das hängt davon ab, was zu holen ist und wie verbreitet die Software ist und wo der Angreifer sitzt?
Wo sitzt der Angreifer?
Falls mein Geschäft eine Oneman-Show ist und die Software nur auf einem Einzelarbeitsplatz läuft, dann dürfte der Angriff am ehesten über das Internet erfolgen, z.B. durch Ausnutzen einer bekannten, noch ungelösten Lücke (z.B. Internet-Explorer oder Flash) oder einfach per Mailanhang z.B. (präpariertes PDF). Der Schädlich könnte schauen, ob er in der Registry das SA-Kennwort findet, anhand des ebenfalls dort stehenden Schlüssels entschlüsselt und ggf. via SQL Server sein schändliches Werk tun.
Falls der SQL-Server im Netzwerk auf einem Server installiert ist, dann dürften mehrere Mitarbeiter vorhanden sein. Für jeden Arbeitsplatz gilt die gleiche Angriffsmöglichkeit wie beim Einzelplatz. Zugleich kommt noch hinzu, dass ein Mitarbeiter anhand einer der vielen Anleitungen einen Sniffer startet (sehr einfach, auch für absolute Laien), das SA-Kennwort erspäht (dito) und dann die Grenzen der Möglichkeiten erprobt (mit Excel zum SQL Server verbinden ist nicht schwer, über SQL Server andere Dateien auslesen erfordert schon mehr Skills). Je nach Motivation des Mitarbeiters kann er sich dann austoben: Die Möglichkeiten reichen vom Stillen der Neugier (steht dort auch, was die Kollegen verdienen) und Kundendaten mitnehmen (um den geplante Start in sie Selbstständigkeit zu erleichtern) bis hin zur Rache (Festplatte formatieren, weil Gehaltserhöhung nicht bekommen, MS fühlt sich ungerecht behandelt, ihm wurde gekündigt, …)
Weil es geht…
In den letzten Jahren kam ein Trend auf, der alle obigen Ausführungen relativiert. Mit den sogenannten Skript-Kids kamen Angriffe hinzu, wo die Angreifer keine wirtschaftlichen Betrachtungen anstellen: Lohnt sich der Aufwand, was ist zu holen, … ? Gerade weil es so einfach ist, werden von meist Jugendlichen Angriffe ausgeführt, einfach nur weil es geht und sie Grenzen austesten wollen. Die Motivation ist hier der Spaß am Knobeln und vielleicht der Prestige-Gewinn im Freundeskreis. Weil es ihnen nicht darum geht damit Geld zu machen, ist es ihnen egal wie lange sie dafür brauchen, sie haben ja nach der Schule meist viel Zeit. Viele der besonders populären Angriffe der letzten Jahre auf Sony etc. waren so motiviert. Die öffentliche Bestrafung einiger der Skript-Kids führte aber in meinen Augen nicht dazu, dass weniger Angriffe durchgeführt werden. Die Kiddies prahlen damit halt nicht mehr so öffentlich.
Und die benötigte Kenntnisse? SQL lernen bayerische Gymnasiasten in der 9ten Klasse…
Update 3.2.2013: Zuschriften entnahm ich, dass einige nicht glauben, dass auch mit normalen Benutzerrechte die beschriebenen Spionageaktionen möglich sind. Daher können interessierte Entwickler anhand dieser Anleitung die benötigten Rechte selber überprüfen.
JTL-Wawi und das veröffentlichte SA-Passwort
Durch die installation der Software JTL-Wawi-Full holt man sich ein gravierendes Sicherheitsproblem aufs System, wenn man einfach nur die Standard-Installation gemäß Anleitung durchführt: Man hat dann einen SQL Server 2005 SP2 (Express Edition), der im Systemkontext läuft und ein fest vorgegebenes SA-Passwort hat. Das SA-Kennwort steht zudem öffentlich in der erwähnten Anleitung.
Warum ist das ein Problem?
Der SQL Server-Dienst läuft im Systemkontext. Alle Aktionen, die über ihn ausgeführt werden, haben daher potentiell Windows-Admin-Rechte. Die installierte SQL-Server-Instanz heißt auch auf jedem System gleich und der Kunde wird angeleitet den nötigen Port in der Firewall freizugeben. Daher kann jeder drittklassige Hacker sich über die gängigen Ports mit dem SQL Server als SysAdmin verbinden (Instanzname, Name des SA und dessen Passwort sind ja gut dokumentiert).
Damit kann der Angreifer allerlei Schabernack anstellen:
- Er kann alle Daten ändern und löschen.
- Er kann sogar den Gastrechner komplett übernehmen: heimlich oder destruktiv. Dem Angreifer sind im Prinzip keine Grenzen gesetzt.
- Er kann beispielsweise Windows-Benutzer mit Windows-Admin-Rechten anlegen,
- Software aus dem Internet nachladen und installieren oder
- einfach nur zerstörerisch wirken (Festplatten formatieren, …).
Leider ist es für einen Anwender fast unmöglich alle Lücken zu stopfen, weil laut Anleitung der SA für die normale Arbeit der Anwendung genutzt wird. Offensichtlich gibt es kein SQL-Benutzer- und -Rechtekonzept. Ein verantwortungsvoller Admin müsste in der Datenbank selber eine Gruppe mit den nötigen Rechten anlegen. Dazu muss er per Try&Error ausprobieren, welche Rechte auf welche Objekte im laufenden Betrieb mindestens benötigt werden. In der Anwendungsdatenbank "eazybusiness" sind jedenfalls keine Rollen oder Benutzer angelegt und damit auch keine dedizierten Rechte.
Was jetzt?
Weil die oben genannten Angriffspunkte von dem Hersteller ganz unschuldig bereits im Internet kommuniziert wurden, hilft die übliche Geheimhaltung auch nicht mehr weiter. Außerdem machte einer der Geschäftsführer auf meinen sehr ausführlichen Hinweis hin deutlich, dass er seine Firma hier nicht in der Pflicht sieht. Aus seiner Sicht können sie den Admin nicht ersetzen. Das verstehe ich so, dass der Admin des jeweiligen Kunden dafür verantwortlich sei die problematische Installation zu erkennen und Gegenmaßnahmen zu treffen. Als Beispiel wird in der Mail das Ändern des SA-Passwortes genannt. Immerhin wurde daraufhin eine Woche später, am 12.11.2012, ein entsprechender Hinweis in die Anleitung aufgenommen (vorher fand ich das auf deren Web-Seite nur tief vergraben in der FAQ):
Für maximale Sicherheit sollte auf jeden Fall das Standard Datenbankpasswort "[Anm.: Passwort entfernt]" geändert werden.
Außerdem solle – laut dem neuen Hinweis – der Zugriff via Firewall auf bestimmte Clients eingeschränkt werden. Aus meiner Sicht ist das aber eher die minimale Sicherheit, nicht die maximale …
Die Antwort der Firma nötigte mir Respekt vor deren Kunden ab. Nur wenige Admins, die ich kenne, haben die nötigen Kenntnisse, um die minimalen Rechte zu erforschen (z.B. mit Profiler) und zu vergeben. Außerdem ist das Benutzerkonzept des SQL Servers nicht gerade trivial. Ich wäre froh, wenn unsere Kunden alle solche Admins hätten, die mit SQL-Experten mithalten können. Normale Anwender wären damit jedenfalls hoffungslos überfordert.
Anhand der Beiträge in den Foren kann man erkennen, dass aber nicht alle Kunden derartig gut ausgebildete Admins haben, sondern sich sogar für einfache Dinge wie Backups durchwurschteln und bei der Problembeschreibung deren Batches inkl. SA&Passwort ins Forum stellen. Daher dürften diese Kunden vom Anspruch des Herstellers überfordert werden, die Probleme alleine zu erkennen und zu lösen. Ich finde es schade, dass diese Kunden mit den durch die Standard-Installation verursachten gravierenden Sicherheitsproblemen alleine gelassen werden.
Wenn man lange sucht, findet man einzig den Hinweis, wie man das SA-Passwort ändert. Direkt darunter steht übrigens aus welcher Tabelle man die Namen und Passwörter der Anwendungsbenutzer im Klartext auslesen kann, die für die Anmeldung am System genutzt werden. Kein Witz.
Welche Maßnahmen wären aus meiner Sicht für eine minimale Sicherheit des SQL Servers nötig?
- Der Hersteller sollte in der Installation des SQL Server kein festes SA-Kennwort mehr vergeben. Außerdem eine Anleitung veröffentlichen, wie bestehende Kunden die gemischte Authentifizierung nachträglich ausschalten können.
- Wenn für den Admin die Windows-Authentifizierung genutzt wird, dann kann man sich das ganze Theater mit dem öffentlichen SA-Passwort sparen. Alle Batches können wir bisher veröffentlicht werden ohne das Schaden entsteht.
- Außerdem sollten mit der Datenbank die benötigten Gruppen und User bereits angelegt werden oder wenigstens entsprechende Skripte veröffentlicht werden. Die Doku sollte beschreiben, wie man einen Windows-Benutzer für die Anwendung im SQL Server anlegen kann, dass der Zugriff möglich ist. Dann muss kein SQL-SysAdmin für den laufenden Betrieb genutzt werden.
Als Kür käme dann noch ein echtes Benutzerkonzept mit einer dedizierten Rechtevergabe. Offenbar gibt es schon die Möglichkeit im System Benutzer anzulegen. Wenn die Benutzer nur auf Views zugreifen dürften, die deren Rechte gegen eine Rechtetabelle prüfen, dann wäre das nochmal erheblich näher an einem sicheren System.
Warum reicht es nicht aus, einfach nur das SA-Passwort zu ändern?
Der Anwender startet die Anwendung bei sich lokal auf dem PC. Wenn die Anwendung generell mit SysAdmin-Rechten arbeitet, dann kann man mit idiotensicheren Werkzeugen das Passwort des SA ausspähen. (Nein, eine Anleitung werde ich nicht geben.)
So (oder, falls er es umständlich mag, mit einer der üblichen Injection-Attacken) könnte ein Mitarbeiter den Server übernehmen oder einfach nur löschen. Das gilt freilich auch für Remote-Angriffe via Trojaner oder präparierte Webseiten.
Aber auch das ist nicht wirklich nötig, weil die Zugangsdaten (ODBC-DSN, User und Passwort) in der Registry unter HKCU gespeichert werden, immerhin leicht verschlüsselt. Ich habe kurz überlegt, ob ich mal mit einem API-Tracer schaue, ob ich sehe, welche Methoden genutzt werden, aber dazu hatte ich dann keine Lust, weil es einfachere Möglichkeiten gibt…
Welche Sofortmaßnahmen wären für betroffene Nutzer sinnvoll?
Ein Nutzer ohne tiefe SQL-Kenntnisse hat in meinen Augen keine Chance das System effektiv abzusichern. Daher sollte er sofort den SQL Server-Dienst deaktivieren, bis es eine ausführliche Anleitung gibt, wie der Kunde den SA disablen und Windows-Authentifizierung nutzen kann. Dazu kann man unter "Dienste" auf den Dienst "SQL Server (JTLWAWI )" rechtsklicken und in den Eigenschaften den Starttyp "Deaktiviert" konfigurieren.
Wenn er SQL-mäßig fit ist, dann muss er wenigstens den SA disablen (oder umbenennen oder gigantsich langes Passwort geben) und andere SQL-Benutzer anlegen, die nur die Werte in den benötigten Tabellen ändern dürfen, nicht aber Admin-Rechte haben (auch nicht DBO). Sie müssen auch sehr lange PAsswörter haben, um Brute-Force-Attacken zu bestehen (>20 Zeichen). Dazu ist der Einsatz des SQL Server Management Studio Express zu empfehlen. Besser sollte er die Vollversion des SQL Servers kaufen, dann kann er mit dem SQL Profiler die Anwendung aufzeichnen und dann damit die benötigten Rechte erforschen. Dabei könnte es man bemerken, dass manche Funktionen nicht klappen, falls diese doch SysAdmin-Rechte benötigen.
Wer rettet die unkundigen Betroffenen?
Der Download der Software ist frei. Es ist Freeware, aber offenbar nicht Open Source. Was heißt das in Bezug auf Sicherheit? Einem geschenktem Gaul schaut man nicht ins Maul?
Wer sich fragt, wovon die Firma lebt, wenn sie die Software verschenken: Sie verkaufen Zusatzmodule unter dem Motto "Professionelle Softwarelösungen für Ihren Erfolg im E-Business". Den Spruch finde ich unter den gegebenen Umständen beachtlich.
Naja, durch den kostenlosen Download kann das immerhin jeder von Euch selber nachschauen. Bei dem Paket "JTL-Wawi-Full" wird die SQL Server 2005 Express Edition mit besagter Konfiguration mitgebracht, seltsamerweise nicht die Ausgabe mit erweiterten Diensten (also mit Management Studio Express). Wer sich Lorbeeren verdienen möchte, kann ja mal erforschen, was zur tatsächlichen "maximalen Sicherheit" nötig wäre und die Skripten dort im Forum veröffentlichen. Es schaut nicht so aus, als ob die Firma das machen würde. Wobei mir unklar ist, warum sie die Situation so gelassen sehen. Meine Warnung hat daran nur wenig geändert.
Freiwillige vor… Das wäre auf jeden Fall eine gute Tat.
Offive 365 erzwingt am SQL Server maximal 16 Zeichen lange Passwörter
Als bei unseren Kunden Probleme mit der Passwortlänge auftraten, konnte ich es kaum glauben: Angeblich gab es Probleme, weil die Passwörter unserer Funktionsbenutzer am SQL Server zu lang waren. Dazu muss man wissen, dass der SQL Server die am Server eingestellten Windows-Passwort-Policies berücksichtigt.
Tatsächlich findet eigentlich auch Microsoft, dass lange Passwörter besser sind als kurze. Dennoch hat Microsoft dokumentiert, dass die Installation des "Office 365 Integration Module (OIM)" die am Server eingestellten Passwort-Policies ungefragt verändert. Anschließend dürfen Passwörter maximal 16 Zeichen lang sein. Daher gab es bei unseren Kunden Probleme, weil für unsere Anwendungen vor Ort grundsätzlich längere Passwörter generiert werden. Längere Passwörter verstoßen aber gegen die durch Office 365 erzwungenen vereinfachten Passwort-Regeln. Microsoft drückt es im Artikel "What should I know about password policies?" so aus:
Note
If you install the Office 365 Integration Module (OIM), the OIM configuration wizard enforces the Strong password policy, and updates the policy to include the following requirements:* Passwords must contain 8–16 characters.
* Passwords cannot contain a space or the Office 365 email name.
Das klingt nicht weiter spektakulär. Man muss schon verstehen, was gemeint ist:
- Die besonders erwähnte "strong password policy" ist ohnehin schon Default. Das steht jedenfalls im gleichen Dokument. Das könnte man also als Nebelkerze betrachten.
- Mit "8-16 characters" ist gemeint: mindestens 8, aber höchstens 16 Zeichen.
Die Regeln werden also aus Kundensicht unsicherer. Leider kann man die Regeln offenbar danach nicht wieder manuell verändern und auch lange Passwörter erlauben. Laut Microsoft ist das ein Feature, kein Bug.
Unglaublich? Aber wahr.
Zwei seltsame Security-Fixes für SQL Server
In den letzten Monaten kamen – nach langer Pause – mal wieder zwei Security-Fixes für das Paket "SQL Server". Sie betrafen tatsächlich aber nicht die DAtenbank-Engine, sondern die Werkzeuge außen rum:
Im August wurden im Bulletin MS12-60 eine Reihe von Patches veröffentlicht, die durch einen Fehler in den "allgemeinen Windows-Steuerelementen" aus Office 2003 (KB2687323) und Office 2008 (KB2687441) verursacht wurden. Hier wurde jeweils eine "Remote Code Execution" beseitigt. Offensichtlich werden sie in den älteren Versionen des SQL Servers benutzt, vermutlich im SQL Server Management Studio. SQL Server 2012 ist nicht betroffen.
Im Oktober wurden im Bulletin MS12-70 Patches für alle SQL Server-Versionen veröffentlicht. Hier ist der Fehler in den "SQL Server Reporting Services". Durch den Fehler kann eine "elevation of rights" verursacht werden. Möglicherweise kannte man den Service durch einen Buffer-Overflow oder eine ähnliche Lücke dazu bringen eigenen Code auszuführen.
Sicherheitslücken in Software und die Verschwiegenheit
Es ist gängige Praxis, dass Entdecker von Sicherheitslücken sich an den Hersteller wenden und vorerst nicht über die Lücke informieren, damit davon keine Gefährdung für die Kunden ausgeht. Erst nach dem die Lücke geschlossen wurde, stellen die Entdecker ihre Infos online. Leider kann das schon mal einige Zeit dauern.
Das kann dann auch schief gehen, wie man bei Heise.de nachlesen kann:
Nach dem letzten Patchday erklärte Oracle eine schwerwiegende Lücke der Oracle Datenbank für gefixt. Der Entdecker veröffentlichte daraufhin konkrete Details mit denen man die Lücke an seinen eigenen Systemen nachvollziehen kann. Doch obwohl nahezu alle produktiven Oracle-Installationen gefährdet sind, gibt es für die gar keinen Patch – viele Oracle-Systeme stehen somit sperrangelweit offen.
Die von Oracle vermeldeten Sicherheits-Fixes bezogen sich ausschließlich auf das noch nicht veröffentlichte Oracle 12; aktuell verfügbar ist derzeit Oracle Database 11.2.0.3.
Dabei geht es um eine sehr schwerwiegende Lücke, die ein Angreifer nutzen kann, um sich Admin-Zugriff zum Oracle-System zu verschaffen. Die Lücke wurde im Jahre 2008 gemeldet und ist noch immer offen. Leider gibt es nur wenige umständliche oder teure Möglichkeiten sich dennoch zu schützen, wenn man Oracle-Nutzer Load-Balacing benötigen. Daher dürften bis zum Fix durch Oracle wohl sehr viele Systeme weiterhin anfällig für diese Angriffe sein.
Bei Heise-Security wird die Situation als sehr ernst eingeschätzt:
Alexander Kornbrust, Experte für Oracle-Sicherheit bei Red-Database-Security schätzt diese Sicherheitslücke als besonders ernst ein, "weil ein Angreifer remote und ohne Kennung auf dem Datenbankserver den Netzwerkverkehr der Datenbank über einen eigenen Server umleiten und danach mitlauschen kann. Lediglich die Oracle SID beziehungsweise Oracle Servicenamen muss ihm bekannt sein."
Das ist schon irgendwie blöd, dass die Schwachstelle öffentlich wurde. Aber muss es wirklich sein, dass Oracle nach vier Jahren immer noch keinen Fix liefert. Ist es nicht wahrscheinlich, dass inzwischen auch noch Andere diese Lücken entdeckten und professionelle Hacker längst darüber Bescheid wussten? Laut dem Finder Joxean Koret besteht die kritische Lücke vermutlich bereits seit 13 Jahren…
Details:
- Heise Security: Oracle-Datenbanken anfällig für eingeschleuste Lauscher
- Heise.de: Kritische Sicherheitslücke in Oracle-Datenbank verplappert
- Joxean Koret : The history of a -probably- 13 years old Oracle bug: TNS Poison
Update 2.5.2012: Auf Heise-Security wird berichtet, dass Oracle das Problem und einen Workaround nun auch beschreibt.