Glorf IT

Bei Heise.de entdeckte ich heute das Whitepaper "Anatomie eines Sicherheitsverstoßes – Warum es zu Datensicherheitsverstößen kommt … und was Sie dagegen tun können" von Symantec. Um es zu bekommen, muss man erst mal einen Heise-Account einrichten, dann muss man noch etliche persönliche Informationen angeben, unter anderem Name der Firma, Daten über die Firma und die eigene Position und das Aufgabengebiet (Pflichtfelder), aber man kann auch bspw. "secret" beim Firmennamen eintragen, was sicher nicht nur für Privatleute oder Studenten vorteilhaft ist. Wenn es dann an den Download geht, dann gehen diese Infos offenbar an Symantec, die aber auch noch unbedingt eine Telefonnummer haben wollen. Auch hier habe ich ausprobiert, dass man bspw. "0000000" eintragen kann. Seltsam, dass die da keinen Zusammenhang zum Titel des Whitepapers sehen: Daten, die sie nicht haben, können nicht verloren gehen bzw. missbraucht werden…

Das Whitepaper an sich enthielt für mich keine neuen Informationen, nur eine Grafik, die leider nicht erklärt oder im Text angerissen wird und die Entwicklung der Angriffsarten aufzeigt (in %). Da die Summe pro Jahr der Angriffsarten aber bei 230% liegt, wäre eine Erklärung scher hilfreich gewesen. Das Dokument ist vermutlich geeignet, wenn man für das Management externe Referenzen für Aussagen rund um Security braucht.

Hier ist das Inhaltsverzeichnis, um einen Eindruck über die behandelten Themen zu bekommen:

Einführung. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Warum treten Datensicherheitsverstöße auf? . . . . . . . . 2
Wohlmeinende Mitarbeiter . . . . . . . . . . . . . . . . . . . . . 2
Zielgerichtete Angriffe . . . . . . . . . . . . . . . . . . . . . . . 3
Mitarbeiter mit böswilligen Absichten . . . . . . . . . . . . . . 5
Was bedeutet das? . . . . . . . . . . . . . . . . . . . . . . . . . 6
So lassen sich Datensicherheitsverstöße stoppen. . . . . . 7
Machen Sie den ersten Schritt . . . . . . . . . . . . . . . . . . 10
Warum Symantec? . . . . . . . . . . . . . . . . . . . . . . . . . .10
Anhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Manche Firmen reagieren recht unwillig oder undurchsichtig auf Meldungen von Sicherheitsbedrohungen, wie ich neulich berichtete. Aber es geht auch anders: Mozilla und Google belohnen die Melder sogar mit Geld und T-Shirts:

Die Mozilla Foundation belohnt Entdecker von Sicherheitslücken ihrer Software künftig mit jeweils 3000 US-Dollar. Bislang waren im Rahmen des 2004 gestarteten "Mozilla Security Bug Bounty Programs" lediglich 500 US-Dollar als Erfolgsprämie ausgeschrieben. Außerdem darf sich der Bug-Finder nun über ein T-Shirt freuen.

Der Grund für die Erhöhung ist offenbar der gewachsene Konkurrenzdruck: auf dem schwarzen Markt bekommen Cracker wohl deutlich mehr 500 USD für das Verkaufen an potentielle Kriminelle. Dabei könnte der Verkauf von derartigem Wissen sogar legal sein. Für die Käufer ist das freilich nur dann interessant, wenn die Firmen die Lücken nicht so bald erfahren…

Schon komisch, dass Firmen wie Microsoft, Apple oder Oracle sich bei den Meldern noch nicht mal ordentlich bedanken. Geld gibt es von denen auch nicht.

Weitere Details und Hintergründe bei heise online.

Wie bekommen Cracker Zugang zu Rechnersystemen in einer bestimmten Firma? Sie müssen versuchen in die internen Systeme einzudringen. Da gibt es verschiedene Möglichkeiten. Wenn kommerzielle Interessen eine Rolle spielen, dann wird der Bösewicht gerne ein paar Dollar ausgeben und speziell präparierte USB-Sticks auf oder vor dem Gelände der Firma verlieren. Was passiert, wenn jemand einen USB-Stick findet?

Ich meine was passiert, wenn eine normaler Mitarbeiter (keiner aus der IT-Abteilung, sondern ein Sachbearbeiter aus einer Fachabteilung) so einen Stick auf dem Weg zur Arbeit findet? Wird er mal schauen, ob er rausfindet wem der Stick gehört, wie groß er ist oder was drauf ist? Ja, wird er.

Sobald er das Teil ansteckt, kommt der Dialog, dass irgendwelche Treiber installiert werden und ein Dialog, ob dem Anbieter des Treibers vertraut werden soll. Wenn der Anbieter schon sein Zertifikat hinterlegt hat, kommt der Dialog nicht. Und schon ist der Rechner verseucht und die Spionagesoftware installiert. Genau das passierte offenbar im großen Stil auf der Suche nach bestimmten Daten.

Die Schadsoftware wurde via USB-Sticks verbreitet und nutzt Lücke in der CommandShell von Windows, um erweiterte Rechte zu bekommen. Irgendwie schafften die Cracker die Software mit einer durch Realtek erstellten Signatur glaubwürdig zu machen (Quelle: krebsonsecurity.com):

Ulasen said the malware installs two drivers: “mrxnet.sys” and “mrxcls.sys.” These so-called “rootkit” files are used to hide the malware itself so that it remains invisible on the USB storage device. Interestingly, Ulasen notes that both driver files are signed with the digital signature of Realtek Semiconductor Corp., a legitimate hi-tech company.

Jetzt interessiert mich natürlich, ob man rausfinden kann, wie die Signatur zu Stande kam?

Ist die Software erst mal installiert, sucht sie nach einer bestimmten Zugriffssoftware und schnüffelt rum. Sie nutzt, dass die Siemensanwendung offenbar in der Regel das Default-Passwort am SQL-Server nutzt (Quelle: Heise Online):

Darin steckten auch die Variablen UID=WinCCConnect und PWD. Nach Angaben des Antivirenherstellers F-Secure sollen WinCC-Anwender angehalten sein, diese Daten nicht zu ändern. Dies würde bedeuten, dass möglicherweise weltweit zahlreiche Systeme dieselben Zugangsdaten zur Datenbank aufweisen. Eine Antwort von Siemens auf eine Anfrage von heise Security steht noch aus.

Und warum macht man das? (Quelle: krebsonsecurity.com)

“Looks like this malware was made for espionage,” Boldewin said.

Die gefundenen Daten scheinen den Aufwand zu rechtfertigen…

Ich fand eine weitere Security-Zeitschrift zum freien Download: "Information Security Magazine". In der Liste findet man die älteren Komplettausgaben als PDF. Auch hier sind die Artikel meist Level 200.

Der Artikel "Database activity monitoring keeps watch over your data." in der Mai-Ausgabe 2010 (Seite 19) könnte beispielsweise für Einsteiger interessant sein, bleibt aber doch recht Oberflächlich. So wird bspw. geraten die abgesetzten Statements zu überprüfen, um seltsame Dinge zu erkennen, wie "WHERE 1=1", um SQL-Injection zu erkennen. Konkrete Umsetzungsvorschläge bleibt der Artikel aber schuldig.

Es ist schon interessant, wie Firmen damit umgehen, wenn jemand in deren Software eine Sicherheitslücke entdeckt und Ihnen das sagt. Böse Menschen würden das für sich behalten und mit dem Exploit viel Geld verdienen. Andere sind ehrlich und geben die Info zur Behebung an die Firmen und/oder an die Betroffenen weiter, damit man sich darauf einstellen kann. Bei TecChannel wird beschrieben, dass eine Firma einen Sicherheitsexperten bedrohte, der einen Vortrag über seine entdeckten Schwachstellen halten wollte: er solle verhaftet werden.

Statt die Probleme zu beheben, scheinen sich die Hersteller nun auf Drohungen zu konzentrieren. Die Geldautomaten-Macher wollen Chisea im Falle des Nicht-Schweigens verhaften lassen. Chisea hatte aber bereits mehrere Auftritte bei anderen Konferenzen mit einer ganz ähnlichen Rede.

In der Vergangenheit war es meist so, dass die Firmen die Info bekamen und der Finder sie erst dann veröffentlichte, wenn die Firma einen Patch dazu auslieferte. Wie man hört, soll das aber durchaus mehrere Monate gedauert haben. Die Finder bekamen nichts, nur manchmal eine Nennung in dem Security Bulletin. Das Problem dabei: Bösen Jungs wussten möglicherweise längst um die Schwachstellen, die Anwender aber nicht und konnten sich nicht schützen. Deswegen konnten Hacker auch so bequem bei Google eindringen, obwohl MS die Schwachstelle schon kannte (aber nicht darüber informiert hatte und auch noch keinen Fix erstellt hatte). Das nennt man "non disclosure", weil der Finder nur den Hersteller informiert und ihm die vollständige Veröffentlichung überlässt. Hier haben es die Hersteller wohl etwas zu bunt getrieben, denn auf diese Bedingungen wollen sich viele nicht mehr einlassen.

Wird der Hersteller vorab informiert und erst nach einer gewissen Reaktionszeit die Benutzer, dann nennt man das übrigens "Responsible Disclosure" (verantwortungsbewusstes Aufdecken).

So machte es auch der seit kurzem bei Microsoft in Ungnade gefallene Tavis Ormandy, der dachte, er habe selber einen Workaround gefunden und veröffentlichte die Schwachstelle samt Behebung nur ein Wenige Tage nach der Info an MS. Aber die Schwachstelle war noch schlimmer als angenommen und MS war unter Druck. Die harsche Kritik an dem Entwickler ist wegen der kurzen Reaktionszeit einerseits verständlich, aber andererseits auch überzogen. Da MS in anderen Fällen erst nach vielen Monaten über die von ihm gemeldeten Probleme berichtete, kann ich verstehen, dass er seine Lösung schnell unter das Volk bringen wollte.

Als Reaktion auf einen gemeldeten Security-Bug den MS angeblich nicht oder nur sehr spät beheben wollte hat sich eine Gruppe gebildet, die sich der "full disclosure" (volle Offenlegung) verschrieben hat: Alle Infos werden sofort veröffentlicht, damit sich jeder schützen kann. Das ist dann sinnvoll, wenn man davon ausgeht, dass die Bösen den Angriff schon kennen. Falls nicht, dann lernen die sicher auch gerne dazu. Sie nennen sich "Microsoft-Spurned Researcher Collective" (MSRC). Kurz nach deren Veröffentlichung des Problems gab es schon bald Exploits und nun wird es Microsoft wohl doch schnell fixen müssen… Ich muss sagen, dass ich die Leute von der MSRC verstehen kann, denn auch meine gemeldeten Verwundbarkeiten stuft Microsoft bis heute nicht als Security-Probleme, sondern als Feature-Request ein und wird sie erst mit dem nächsten Visual Studio (?2012) beheben.

Wie ich neulich bei Heise las, gibt es neuerdings auch Firmen, die Sicherheitslücken gar nicht an die Hersteller weiter leiten, sondern das gewonnene Know-How als Marktvorteil nutzen: Nur die eigenen Kunden werden gewarnt und geschützt, der Rest der Welt darf weiter von Crackern angegriffen werden. Das ist auch eine direkte Reaktion auf die zurückhaltende Informationspolitik der großen Firmen: Man macht ein Geschäftsmodell daraus. 😉

Heute machte ich mich auf die Suche nach Zeitschriften zum Thema "IT-Security". Ich möchte hier gerne up to date bleiben und da erscheint mir eine auf dem Weg zur Arbeit gelesene Zeitschrift ein bequemer Weg. Dabei traf ich auf die Zeitschrift "Hackin9". Sie ist offenbar eher Level 200, was mir bei manchen Gebieten durchaus entgegen kommt. Ich las die Ausgabe 6, die mich noch nicht wirklich beeindruckt hat. Ich schätze der Artikel "Der Penetrationstest – Vorgehen und Tools eines Testers" könnte als Einstieg in das Thema recht interessant sein. Für versierte Fachleute ist das Magazin eher nicht geeignet.

Der Grund für das Posting ist, dass die Zeitschrift offenbar generell als kostenloser Download verfügbar ist (offenbar gibt es keine Print-Ausgabe). Wer in das Thema einsteigen will, der findet hier möglicherweise die ein oder andere Perle.

Hinweis: Wenn man über "Download" geht, dann muss man für den Download alter Ausgaben eine Mailadresse angeben. Über den Menüpunkt "Magazin" nicht.

In dem amüsant geschriebenen how-I-did-it-Artikel "Tatort Internet: Alarm beim Pizzadienst" auf Heise-Online wird erklärt, wie Heap-Spraying funktioniert und warum ein Buffer-Overflow eine ernste Bedrohung darstellt.

Als ich heute las, dass nun auch Julian Assange von den US-Behörden gesucht wird, fragte ich mich wer das eigentlich ist und was ihn antreibt. Hier das bescheidene Ergebnis meiner Sammlung.

Was ist das Problem?

Auf Wikileaks werden regelmäßig geheime Dokumente veröffentlicht, die kein gutes Licht auf die Auftraggeber der Dokumente werfen. Wenn es nicht zu enthüllen gäbe, dann wären sie ja nicht geheim… Das Beispiel um das es hier geht, ist ein Video das 2007 im Irak aus einem US-Helikopter gemacht wurde während 18 Zivilisten von der Besatzung erschossen wurden. Die zynischen Kommentare der Schützen runden das schlechte Bild ab. Derjenige, der das Video an Wikileaks weiter gab, soll auch noch andere belastende Dateien weiter gegeben haben. Da er nun geschnappt wurde, will man nun auch dem Empfänger der Dateien an den Kragen. Denn er könnte die anderen Dateien ja auch noch veröffentlichen. Das möchten die US-Behörden verhindern und schicken ihre Agenten los.

Nun heißt es Julian Assange sei "untergetaucht". Das schließt man daraus, dass er auf einer Konferenz in Las Vegas nicht erschien.

Wer ist Julian Assange?

Ausnahmsweise gibt die Wikipedia hier nicht viel her, nur die groben Lebensstationen:

Julian Assange ([əˈsɑːnʒ]; * 1971 in Townsville[1]) ist ein politischer Aktivist, Journalist und Herausgeber von WikiLeaks. Er ist neben Daniel Schmitt (Pseudonym) das einzige bekannte Gesicht dieser Whistleblower-Plattform im Internet, welche sich zum Ziel gesetzt hat, allen Bürgern Zugang zu geheim gehaltenen Dokumenten zu verschaffen.

Der in Australien geborene Assange studierte Physik und Medizin.[2] Er lebte und arbeitete in China, Iran, Australien, den USA und Großbritannien.[2] Infolge seiner Arbeit wurde er mehrmals verhaftet, abgehört, zensiert und auch erfolglos verklagt.[2]

Assange gewann 2008 den Economist Index on Censorship Award[2] und 2009 den Amnesty International Media Award (New Media)[3] für Berichte über Hinrichtungen ohne Gerichtsverfahren.

Der Artikel "No Secrets" hingegen ist fast zu reißerisch, bringt aber etwas mehr von seinen Zielen und Beweggründen rüber. Besonders bemerkenswert finde ich diese Passage in der es um Wikileaks geht:

The catalogue is especially remarkable because WikiLeaks is not quite an organization; it is better described as a media insurgency. It has no paid staff, no copiers, no desks, no office. Assange does not even have a home. He travels from country to country, staying with supporters, or friends of friends—as he once put it to me, “I’m living in airports these days.” He is the operation’s prime mover, and it is fair to say that WikiLeaks exists wherever he does. At the same time, hundreds of volunteers from around the world help maintain the Web site’s complicated infrastructure; many participate in small ways, and between three and five people dedicate themselves to it full time. Key members are known only by initials—M, for instance—even deep within WikiLeaks, where communications are conducted by encrypted online chat services. The secretiveness stems from the belief that a populist intelligence operation with virtually no resources, designed to publicize information that powerful institutions do not want public, will have serious adversaries.

Ein Leben auf der Flucht? Warum? Um welche Informationen geht es hier?

So far, even though the site has received more than a hundred legal threats, almost no one has filed suit. Lawyers working for the British bank Northern Rock threatened court action after the site published an embarrassing memo, but they were practically reduced to begging. A Kenyan politician also vowed to sue after Assange published a confidential report alleging that President Daniel arap Moi and his allies had siphoned billions of dollars out of the country. The site’s work in Kenya earned it an award from Amnesty International.

Offenbar geht es schlicht und einfach darum zu verhindern, dass die Mächtigen dieser Welt ihre Untaten vertuschen können. David gegen Goliath. Das scheint ja bislang zu klappen. Aber ist es den Preis den Assange dafür zahlen muss wirklich wert? Man darf nicht vergessen, das ist echt, kein Film. Wenn er erwischt wird, dann wird er wohl reihenweise verklagt und landet für sehr lange Zeit im Gefängnis.

Wenn ich mir die Story über ihn durchlese, dann scheint ihm das nur zu bewusst zu sein, aber er hat sein Lebensziel definiert: eine Plattform zur Veröffentlichung von geheimen Schweinereien aufzubauen…

Wenn man in den letzten Wochen so die Nachrichten verfolgt, dann hat sich der Ton zwischen Google und Microsoft in Sachen Security deutlich zugespitzt. Noch letztes Jahr meldete Google gefundene Sicherheitslücken und wartete danach brav monatelang auf einen Fix von Microsoft.

Nach den für Google peinlichen Hackerangriffen, hieß es dort intern "Und tschüss, Windows". Die damals bei Google ausgenutzte Lücke in Windows und im Internet-Explorer wird hier in Detail beschrieben.
Sie war Microsoft offenbar schon länger bekannt, aber wurde erst nach dem Angriff beseitigt. Die Lücke konnte auf IE6 bis IE8 ausgenutzt werden. Zunächst war angenommen worden MS hätte recht gehabt mit dem Hinweis, dass die Lücke und auf IE6 ausnutzbar gewesen sei. Daraufhin wurde mit leichter Häme angenommen, dass bei Google reihenweise noch IE6 auf Firmenrechern im Einsatz gewesen seien. Diese Argumentation ist nun hinfällig und Experten sind eher geneigt Google nun zu glauben. Und es erklärt möglicherweise auch warum Googles Leute mit MS keine Geduld mehr haben…

Im Heise-Artikel "Windows-Hilfe als Einfallstor für Angreifer" stehen Details zu einer neuen Lücke, die als kritisch einzustufen ist. Weil der Google-Entwickler glaubte eine Abhilfe gefunden zu haben, informierte er kurz nach Microsoft auch die Öffentlichkeit. Was nun wiederum Microsoft verärgert, denn die Lücke ist noch größer als angenommen und schwerer zu stopfen. Details und einen Workaround hat nun auch Microsoft veröffentlicht. Eigentlich finde ich das Vorgehen des Google-Entwicklers nicht gut, man sollte den Firmen ausreichend Zeit für den Fix geben. Die Annahme, dass die Lücke sonst niemandem bekannt sei und daher bisher noch nicht ausgenutzt werde, scheint aber bei Microsoft zu einer Verschleppung der Probleme zu führen, die zu den oben genannten Hackerangriffen führten. Das geht nun gar nicht.
Das Ergebnis gibt dem Google-Entwickler nun leider recht. Vermutlich hätte es wieder Monate gedauert bis Microsoft über die Lücke informiert hätte. So kann man sich wenigstens schützen.

Ich bin schon mal auf die nächste Runde im Security-Spiel "Google versus Windows" gespannt…

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… 😉