Glorf IT

Frisch aus dem Urlaub zurück überraschte mich bei Heise die Nachricht, dass eine mir bisher unbekannte Firma ein Sicherheitsproblem am Microsoft SQL-Server entdeckt und veröffentlicht habe. Sie meldeten das Problem Ende 2008 an Microsoft und die signalisierten, dass das aus deren Sicht keine relevante Lücke sei und nicht behoben wird. Sentrigo schrieb daraufhin ein Tool, dass diese Lücke ausnutzt um sie zu beheben. Dazu muss man das Tool aber regelmäßig immer wieder aufrufen. Erst heute kam ich dazu mal die Hintergründe zu recherchieren.

Welche Tragweite hat das Problem?
Hat jemand Windows-Admin-Rechte an dem Computer auf dem der SQL-Server läuft, dann kann der Windows-Admin die Passwörter der angemeldeten Benutzer im Klartext lesen, weil sie in einer internen Tabelle pro Datenbank-Verbindung gespeichert werden. Das betrifft alle aktuellen Systeme: SQL Server 2000, SQL Server 2005 und SQL Server 2008 (die Betas von R2 daher vermutlich auch).

Während in der Login-Tabelle nur der Hash des Passwortes gespeichert ist, werden die Informationen zu angemeldeten Benutzern unverschlüsselt im Hauptspeicher gehalten. Ein Administrator kann nun mit geeigneten Werkzeugen, z.B. OllyDbg, den Hauptspeicher nach den Passwörtern durchsuchen. Sentrigo hat nun das kostenlose Werkzeug Passwordizer gebaut, dass diese Passwörter findet und mit Schrott überschreibt. Hier ein Beispiel:

C:\WINDOWS>E:\temp\Passwordizer\passwordizer\x86\passwordizer.exe 2212
Process is 32bit
DATA section found at 27cf000
Exe name is C:\Programme\Microsoft SQL Server\MSSQL.1\MSSQL\Binn\sqlservr.exe
MSSQL Server version is 90000 10820000
Scanning for sessions table (Can take up to several minutes)
Session table found at 27e6fe8
Getting user passwords for MSSQL Server 2005
Session id: 51
Username: sa
Password: k******9
Password cleared from memory

Sentrigo Passwordizer process completed successfully
1 passwords removed from memory

Im Output steht eigentlich alles was man wissen muss, insbesondere die Adresse an der die Informationen gefunden werden können. Natürlich ist die bei jedem Start anders, aber damit kann man sich das Problem mal aus der nächsten Nähe ansehen, weil man ja jetzt genau weiß wo man suchen muss.

Aber auch remote kann man die Passwörter lesen, wenn man am SQL-Server SysAdmin-Rechte hat. Das geht aber nur am SQL-Server 2000 und 2005, ab 2008er wurde laut Heise.de der dazu nötige DBCC-Befehl aus anderen Gründen entfernt. Im Securosis Blog verrät ein Sentrigo-Mitarbeiter, dass man "DBCC BYTES" dazu verwenden kann. Das ist aber kein großes Geheimnis, denn nur DBCC Bytes ist im SQL Server 2008 nicht mehr vorhanden, alle anderen gibt es dort weiterhin.

Meine Einschätzung: Ich sehe keine realistische Gefahr für die SQL-Server-Kunden, aber Microsoft hat einen peinlichen PR-Gau erlebt.

Warum? Die Sicherheitslücke ist schon sehr exotisch. Man muss schon zuerst mal Windows-Admin oder wenigstens SQL-Server-SysAdmin sein, um die Lücke ausnutzen zu können. Und dann sieht man nur die Passwörter derjenigen die sich aktuell über SQL-Authentifizierung angemeldet haben. Wenn man die von Microsoft empfohlene Windows-Authentifizierung verwendet, sieht man gar nichts. Was kann der Windows-Admin, der immer auch zugleich SysAdmin ist, mit den SQL-Server-Passwörtern anfangen? Gute Frage. Er darf alles tun, was er ohnehin schon als SysAdmin darf: sich als dieser Benutzer ausgeben und am SQL-Server Dinge in dessen Namen tun.

Die Gefahr besteht also lediglich darin, dass der Anwender SQL-Authentifizierung nutzt und das gleiche Passwort auch für sein Online-Banking, E-Bay oder dergleichen verwendet. Das könnte ein krimineller Windows-Admininistrator mal ausprobieren und ggf. dann tun was er möchte. Die Lücke ist in meinen Augen eher eine Kleinigkeit, da Administratoren auch auf viel einfachere Weise die Passwörter Ihrer Kollegen ausspähen könnten. Dennoch ist es natürlich eine Lücke und eine peinliche noch dazu.

Aber für die bisher weitgehend unbekannte Firma Sentrigo war das der PR-Boost schlechthin. Sie haben Microsoft so richtig vorgeführt, weil Microsoft danach schrie. Natürlich hätte Microsoft das ernst nehmen müssen. Man speichert einfach keine Passwörter im Klartext. Warum auch? Ich habe keine Ahnung wie aufwändig die Behebung gewesen wäre, aber da nun mal alle Mitarbeiter mit dem R2 beschäftigt waren, blieb für solche Dinge wohl keine Zeit mehr. Und damit hat sich Microsoft so richtig blamiert.

Vermutlich werden sie es nun doch beheben müssen, sonst müssen sie sich immer vorwerfen lassen, dass sie eine nicht behobene Sicherheitslücke haben. Und diese Diskussionen mag doch keine Firma gerne…

Update 16.9.2009:

• Ja, es geht mittels DBCC BYTES, das wurde schon im Frühjahr im Vortrag "SQL SERVER Anti-Forensics" von Cesar Cerrudo (Folie 18) veröffentlicht.
• Heute bekam ich eine Mail von Firma Sentrigo, die sich für den Download des Tools "Passwordizer" bedankte und fragte an welchen Lösungen von ihnen ich denn Interesse hätte. Hallo? Am Passwordizer natürlich. Ich bereue bei der Angabe der persönlichen Daten ehrlich gewesen zu sein…

In dem Artikel "Advanced SQL Injection In SQL Server Applications" beschreibt Chris Anley (NGSSoftware) sehr ausführlich wie SQL-Injection am SQL-Server funktioniert. Darin findet man problemlos die Anleitung wie man vorgehen muss, um einen SQL-Server mit dieser Lücke zu übernehmen. Natürlich geht er vom schlimmsten Fall aus, dass nämlich die Anwendung Admin-Rechte am SQL-Server hat, aber das ist ja auch nicht ganz unrealistisch.

Das ist eine Pflichtlektüre für jeden, der Software mit Zugriffen aus dem Microsoft SQL Server schreibt. Danach weiß man, was man besser absichern sollte und warum…

Durch den Heise-Online-Artikel "SQL-Injection reloaded: Zugriff auf das Betriebssystem" wurde ich auf das Tool sqlmap aufmerksam. Damit kann man versuchen (eigene?) Systeme mittels SQL-Injection zu kompromittieren.

Sqlmap scheint sich aber vorwiegend auf web-basierte Clients zu konzentrieren. Schade, ich hätte das gerne mal gegen unsere Windows-Anwendungen laufen lassen. Das ist schon deswegen interessant, weil die normalen Benutzer nicht genug Rechte haben sollten, um die vom Tool verwendeten Funktionen (z.B. xp_cmdshell) zu nutzen. Aber wer weiß, vielleicht nutzt es ja vorher eine mir bisher unbekannte Methode der escalation of rights…

Ich wüsste ja gerne mal, wo man die Werkzeuge her bekommt…

How to Opening the Door.lock Inside – The best bloopers are here

Hier wird es noch mal etwas besser erklärt:

How To Do Lock Pick – More bloopers are a click away

Heute bekam ich zum achten oder neunten Mal in den letzten Jahren diesen miesen Aufruf zum Telefonterror, der sich als Bitte um Knochenmarkspende tarnt. Hier ein Auszug aus der heutigen gaaanz eiligen und aktuellen Mail:

Ich wende mich an Euch, weil ich ziemlich verzweifelt bin.
Ich hoffe, Ihr könnt mir und meiner Freundin helfen, und lest diesen
Brief!
Das Problem ist, dass meine Freundin an Leukämie erkrankt ist…
Es hat sich herausgestellt, dass Sie nur noch wenige Wochen zu leben hat.
Aus diesem Grund seid Ihr meine letzte Chance ihr zu helfen.
Wir benoetigen dringend eine/n Spender/in mit der Blutgruppe 'AB Rhesus
negativ', der/die bereit waeren, ggf. Knochenmark zu spenden.
Dies ist fuer Euch nur ein kleiner Eingriff, kann aber meiner Freundin zu
Leben verhelfen.
Wenn jemand diese Blutgruppe hat, möchte er/sie sich doch bitte mit
mir in Verbindung setzen.
Alles weitere besprechen wir.
Sendet bitte diesen Brief an alle, die Ihr kennt!!!
Fragt in eurem Bekanntenkreis nach!!!!!
Ich danke Euch fuer Eure Hilfe!!!

Im weiteren Verlauf werden ein paar Adressen der Uni Regensburg als angebliche Absender und Ansprechpartner genannt, die wohl ihres Lebens nicht mehr froh werden. Wer denen schaden wollte hat das nachhaltig geschafft. Dieser Brief geistert seit dem Jahre 2000 in kaum veränderter Form durch das Internet. Wer mehr Infos will, findet sie bei der Hoax-Info der TU Berlin:

Gerade dieses Beispiel illustriert, welche Gefahr Kettenbriefe in sich bergen:
Sie sind nicht zu stoppen, wenn sie einmal in Umlauf sind. Personen, die sie in bester Absicht weiterleiten und deren ihre Adresse und/oder Telefonnummer vom E-Mail-Programm automatisch angefügt wird, werden ihres Lebens nicht mehr froh. Sie werden wochen-, monate- oder gar jahrelang mit Anfragen zu dem Kettenbrief belästigt. Sie müssen neue Telefonnummern beantragen und all solche unangenehmen Dinge unternehmen um wieder normal leben zu können. Dies sollte allen eine Warnung sein Kettenbriefe nicht weiterzuleiten!

Mit der heutige Mail waren übrigens 182 Absender enthalten an die dieser Aufruf zum Telefonterror ging, die meisten Mailadressen waren sichtbar enthalten (meine auch). Obwohl die Mail jeweils immer nur an 10 bis 30 Adressaten weitergeleitet wurde, ist die Mailadresse der anderen auch nach der x-ten Weiterleitung noch zu sehen. Welches idiotische Mailprogramm ist denn so Spammer freundlich?

Bisher habe die letzten Absender mit freundlichen Worten darüber aufgeklärt, dass sie Opfer einer böswilligen Aktion wurden und gerade dabei mitgemacht haben jemand anderen zu mobben. Die Meisten reagierten bisher ärgerlich auf mich, fühlten sich angegriffen oder fanden ihr Verhalten auch im nachhinein richtig ("Woher hätte ich das auch wissen sollen?" – von Google?). Mal sehen, wie es diesmal ist…

Wer mehr Infos möchte, findet sie im "Hoax – Extra-Blatt: Knochenmarkspende".

Heute erhielt ich Post von einer gemeinen Kröte. Normalerweise lösche ich solche Mails gleich. Aber die war halbwegs plausibel und hatte nur auf den zweiten Blick erkennbar einen Trojaner drin. Deswegen habe ich mir den Spaß gemacht und die Mail näher angeschaut. Hier erst mal der Text:

Guten Tag,
Ihr Auftrag Nr. SP9327678 wurde erfullt.
Ein Betrag von 6220.88 EURO wurde abgebucht und wird in Ihrem Bankauszug als “Paypalabbuchung ” angezeigt.
Sie finden die Details zu der Rechnung im Anhang

PayPal (Europe)
S.941; r.l. & Cie, S.C.A.
67-85 Boulevard Royal
L-2248 Luxembourg

Gruss,
Vertretungsberechtigter: Latoya Crouch
Handelsregisternummer: R.C.S. Luxembourg B 502 263

Als Absender-Adresse dieser angeblichen Paypal-Mail wird "Latoya Crouch" <vhsyxysid@bookreviewclub.com> angegeben, das Betreff ist "Ihre Rechnung N85696203". Abgesehen davon, dass das außerdem noch an meine SPAM-Adresse ging, enthält die Mail ein paar sachliche Fehler, die entweder auf der Dummheit oder mangelnde Sprachkenntnis beruhen:

• Wenn sie mir etwas abbuchen, dann sollte es nicht "Ihre Rechnung" sondern "unsere Rechnung" heißen.
• Der Betrag wird bei uns mit Komma angegeben und nicht mit Punkt. Banker wissen das.
• Was auf meinem Bankauszug steht, wissen die nicht. Aber man kann als Auftraggeber den Überweisungszweck angeben.
• Wer Paypal kennt, wird wissen, wie der Geldtransfer mittels Paypal funktioniert.

Das beiliegende Zip namens "Rechnung_S833.zip" enthielt nur die Datei "Rechnung___________________________________________NRDKJH8833423444229.exe", die so richtig verseucht war.

Der Header der Mail enthielt übrigens:

Delivered-To: GMX delivery to xxx (von mir entfernt)
Received: (qmail invoked by alias); 24 Jul 2008 19:19:16 -0000
Received: from francepub.net1.nerim.net (EHLO francepub.net1.nerim.net) [62.212.108.213]
by mx0.gmx.net (mx081) with SMTP; 24 Jul 2008 21:19:16 +0200
Received: from [62.212.108.213] by mx2.balanced.looney.mail.dreamhost.com; Thu, 24 Jul 2008 20:19:15 +0100

Die Mail wurde also vermutlich von der IP-Adresse 62.212.108.213 abgeschickt. Wobei fraglich ist, ob der Absender wirklich böse ist oder nur sein Rechner gehackt wurde… Vielleicht hat er auf die "Rechnung" geklickt?

Just for fun habe ich mal wieder meine 404er-Fehlermeldungen durchgesehen. Die bekommt der Leser immer dann, wenn er versucht eine Seite aufzurufen, die es nicht gibt. Dabei sah ich, dass seit dem 15.7. (also in drei Tagen ) fast 100 Aufrufe erfolgten, um sich in meinen Weblog zu hacken. Im Kern waren die Versuche alle gleich und versuchten einen Exploit zu finden, der Schadcode ausführt. Dazu sollte der PHP-Code von verschiedenen Servern gerufen werden.

Hier ein paar dieser Dateien, die man sich ruhig ansehen kann. Der enthaltene PHP-Code wird nicht ausgeführt, sondern einfach als Text angezeigt (und wenn würde er auf dem Server ausgeführt und nicht im eigenen Browser):

• http://www.proostjes.be/calendar/help01.txt
• http://beherit.interfree.it/cmd.txt
• http://sagem.ovh.org//a.txt
• http://www.coronaclub.it/pk_gallery/photos/25/11828333/idilegal.txt
• http://dicafree.com/zboard/DQ_LIBS/icon/safe1.txt
• http://www.shaker-diffusion.com/id.txt
• http://web246.webgo24-server11.de/Homepage/fightus/rfi-response.txt
• http://bratki2.ovh.org/templates/rhuk_solarflare_ii/images/.know/…/idbot5.txt
• http://www.bakowales.com/holo.dat?&list=1&cmd=id

Was macht man da? Soll ich die Betreiber der Seiten kontaktieren und um Löschen der Dateien bitten? Ich gehe mal davon aus, dass keiner der Angreifer so dämlich war die Datei von seiner eigenen Seite zu laden, oder?

Erstmals seit Juli 2003 gibt es wieder einen Security-Hotfix für den SQL Server. Der Fehler wird aber nicht als "critical", sondern bloß als "important" eingestuft. Wenn ich es richtig sehe, dann ist jede Version des SQL-Servers betroffen, die noch unterstützt wird! Die Liste seht im Dokument "Microsoft Security Bulletin Advance Notification for July 2008" im Abschnitt "Affected Software". Das Problem besteht darin, dass jemand sich höhere Rechte erschleichen kann, als er sollte ("Elevation of Privilege").

Die Detailinformationen wird Microsoft leider erst am 8.7.2008 veröffentlichen. Bei ENTmag.com fand ich dennoch schon einige Details:

The first important fix addresses an elevation-of-privilege problem in SQL Server. Hackers can gain back-door access into the database and change fields to configure user access parameters, giving themselves superuser or unlimited access to run amok on a network.

In the last week of June, Redmond issued a security advisory pertaining to certain components of SQL Server, citing a recent "escalation in a class of attacks targeting Web sites" and using the database application as an incursion vector. […]

The SQL patch affects Windows 2000 Service Pack 4 and Windows Server 2003 (SP1 and SP2), including 64-bit editions. Windows Internal Database (WYukon) is also affected as the patch relates to all versions of Windows Server 2008 except for Itanium-processor-based systems.

Das klingt so richtig garstig. Schade, dass damit die Serie der Jahre ohne Security-Hotfix für SQL-Server gebrochen ist. Echt sch…

Wer selber Software schreibt, insbesondere ASP-Projekte, der weiß ein Liedchen davon zu singen, dass man sich gegen SQL-Injection wappnen muss. Eigentlich ist das gar nicht schwierig, man darf halt nichts was vom Benutzer oder über Schnittstellen kommt einfach so an die DB weiterreichen. Schlimm ist es beispielsweise, wenn man SQL-Befehle dynamisch zusammensetzt. Dann muss man den Input filtern (z.B. mache aus einem einfachen Anführungszeichen zwei). Alternativ kann man auch mit gebundenen Parametern arbeiten, was sich übrigens auch positiv auf die Performance auswirkt.

Wer sichergehen will, dass diese Probleme in der eigenen ASP-Lösung nicht drin sind, dem bietet Microsoft nun als Unterstützung das Security Advisory 954462 mit dem Titel "Rise in SQL Injection Attacks Exploiting Unverified User Data Input". darin wird auch auf ein neues MS-Tool verwiesen, den "Microsoft Source Code Analyzer for SQL Injection". Mit dem Tool werden ASP.NET-Anwendungen automatisiert untersucht. Das finde ich echt gut.

Eine ganz gute Erklärung wie SQL-Injection funktioniert steht bei Heise.de.

Heute nahm ich wieder einen Artikel vom Stapel, den ich im April las und mir irgendwie aufheben wollte. Jetzt werde ich das Wesentliche einfach bloggen, dann kann ich das Heft dem Recycling zuführen…

In dem Heft 4/2008 von "IT-Mittelstand" beschreibt Dr. Björn Georg (Fa. Retarus) dass man mit PDF-Rechnungen sehr vorsichtig sein muss. Normale PDFs werden nämlich vom Finanzamt nicht als gültige Rechnungen anerkannt. Das Bedeutet bei Privatleuten einfach nur dass man die darin enthaltenen Kosten nicht absetzten kann. Wenn man freiberuflich tätig ist, dann kann es einen noch härter treffen, wenn das Finanzamt auch noch die abgezogenen Vorsteuern zurück haben will. Interessanterweise gilt das auch für normale Rechnungen per Fax.

Laut Dr. Georg werden zunächst mal nur die Rechnungen per Schneckenpost vom Fiskus anerkannt. Alle anderen Formen müssen abgesichert werden. PDFs müssen beispielsweise signiert werden. Dazu muss der Versender aber erst mal in der Lage sein. Und der Empfänger muss die Signatur überprüfen können. Das ist eigentlich gar nicht nicht viel Aufwand, man benötigt lediglich ein gültiges Zertifikat und die Software zum signieren.

Interessanterweise fand ich vom selben Autor zum gleichen Thema auch beim AP-Verlag einen Artikel. Wenn man sieht, dass seine Firma als Dienstleistung anbietet PDF zentral zu signieren, dann weiß man was los ist. Bei der zentralen Lösung stört mich, dass die Signierung nicht mehr mit dem persönlichen Zertifikat des Absender erstellt werden darf, denn der darf seine Signatur nicht an Dritte weitergeben. Auch ist das Absichern des Weges zu dem Dienstleister meiner Ansicht nach nicht weniger aufwändig als das Einrichten der Software um selber zu signieren, oder?

Ich habe mal aus Jux rumgesucht und irre viele Artikel gefunden, die das Signieren von PDFs als einfach beschreiben. Aber Achtung – getestet habe ich keine dieser Lösungen: eine Sammlung bei ITSecCity, PC-Welt, Wrocklage, OpenPR, Secardeo und so weiter …

Vor zwei Wochen berichtete ich darüber, dass ich auf einer Suchseite als Landschaftsgärtner geführt werde – als ob ich einen grünen Daumen hätte… Neben meiner Adresse waren dort auch ein paar meiner Domänen angegeben und eine Mail-Adresse, die ich nicht wirklich nutze. Ich fragte bei dem dort als Datenschutzbeauftragen nach, wie sie denn an die Daten gekommen seien.

Heute bekam ich per Mail Antwort von "t-info GmbH" aus Frankfurt. Ich werde dort wirklich in der Kategorie "Garten- und Landschaftsarchitekten" geführt. Und meine Daten seien nun "als gesperrt gekennzeichnet im Sinne des § 3 Abs. 4 Nr. 4 BDSG, das heißt die Daten werden nicht genutzt oder weitergegeben".

Hier ein paar Auszüge:

2. Herkunft der Daten unter Ziffer 1 (§ 34 Abs. 1 Satz 1 Nr. 1, 2. Halbsatz BDSG)
Die Daten wurden von unserem System von einer frei zugänglichen Internetseite eingelesen.

URL: www.glorfmorph.de, www.kids-im-park.de

Da haben sie schon Glück mit der deutschen Impressumspflicht. Man kann ja wohl nicht verhindern, dass die Seite elektronisch nach Adressen abgerast wird. Aber die Daten ungefragt zu veröffentlichen scheint mir nicht koscher zu sein. Außerdem bietet keine der beiden Seiten eine Anhaltspunkt, dass ich Gärtner sein könnte! Wie kommen die auf so einen Stuss?

4. Zweck der Speicherung

Erteilung von Auskünften an Nutzer des Auskunftsservices unter suchen.de.

Gesperrte Daten: Die Daten werden gespeichert um sicherzustellen, dass 1) wir zur Ihrer Person keine Daten von Dritten erhalten, 2) wir Ihre Daten nicht aus dem Internet einlesen, und 3) Ihre Daten nicht an Nutzer des Auskunftsservices unter suchen.de weitergegeben werden (Sperrung im Sinne des § 3 Abs. 4 Nr. 4 BDSG).

Wenn ich es richtig verstehe, dann behalten sie meine Daten in deren Datenbank, damit sie meine Daten nicht noch mal über andere Webseiten einlesen und versehentlich wieder veröffentlichen. Hm, gutes Argument.

Wir hoffen, dass wir die Angelegenheit in Ihrem Sinne erledigen konnten. Weitere Informationen zur Suche und den Suchergebnissen sowie der Entfernung von Websites finden Sie unter der Internetadresse www.webadress.de im Bereich "FAQ".

Was soll das jetzt bitte wieder heißen? Soll ich alle meine Web-seiten dort angeben, damit sie mich in Ruhe lassen? Ich scheiterte bei dem Versuch mir diese Seite noch mal anzusehen, sie war nicht erreichbar. Vielleicht werden sie mit Löschaufträgen überrannt?

Seitdem ich dem Rat auf Heise.de folgte und den Adobes Flash Player deinstallierte, sehe ich manche Dinge anders.
Hintergrund ist, dass die kürzlich bekannt gewordene Schwachstelle im Adobes Flash Player bereits aktiv von Webseiten genutzt wird, um friedliebenden Besuchern Trojaner unter zu schieben. Deswegen sehen einige Webseiten bei mir plötzlich nicht mehr knallbunt aus, sondern leer…