• AdSense
• AdWords
• Alert
• Analytics
• Android Market
• Docs
• Groups
• Mail
• Plus
• YouTube

Würde man nun alle diese Daten zusammentragen und in einem Datenpool zusammenführen und miteinander verknüpfen, so ergäbe sich ein gewisses Nutzerbild, welches von den Daten aus den täglichen Suchanfragen abgerundet würde.


Einzelne Datensätze nach der Zusammenführung meiner Daten bei Google:

• AdSense
• AdWords
• Alert
• Analytics
• Android Market
• Docs
• Groups
• Mail
• Plus
• YouTube

Ich nutze für jeden Dienst eine eigene E-Mail-Adresse und erschwere es Google alle Daten zusammenzutragen und sich ein Bild von mir zu machen. Und fast alle Dienste nutze ich nur zu Testzwecken.

Wenn Google morgen tot umfallen würde, würde mir nur die Suche fehlen, da dies nach wie vor der einzige Dienst ist, den ich jeden Tag nutze. Aber auch über meine Suchanfragen kann Google nicht so einfach Buch führen, da ich täglich die Cookies lösche bzw. löschen lasse und natürlich bin ich bei der Suche nie in einem Google-Account eingeloggt.

Ja, ich bin böse. ;O)


Wer viele Daten im Netz publiziert und ständig seine digitalen Ausdünstungen zum Besten geben muss, für den ist Google natürlich das ideale Schweißband. Wer aber, auch im 21. Jahrhundert, auf seine Privatsphäre achtet, der kann sehr leicht ohne Google leben und trotzdem die volle Bandbreite der Möglichkeiten des Internets nutzen. Dies mag am Anfang etwas mühseliger erscheinen, als “einfach” Google zu nutzen, aber wer sich nicht von einem Anbieter abhängig macht, der kann sehr flexibel auf die Änderungen bei einem Dienst reagieren ohne dabei alles zu verlieren.

Eine SQL-Fehlermeldung die den AES-Schlüssel ausspuckt:
... encode(decrypt_iv(passwort, 'A*****9', decode(n.iv, 'base64'), 'aes'), 'escape') ...

Den MD5-Hash von cPe64pH,r)?Mz4n39[u@J zu knacken dürfte etwas länger dauern. Aus dem AES-Code das Passwort zu generieren, wenn man den AES-Schlüsselt hat, dürfte hingegen kein Problem sein.

Per SQL-Injection könnten nun alle Daten, denn nicht nur das Passwort ist verschlüsselt, ausgelesen werden, um diese mit dem AES-Schlüssel zu entschlüsseln.


Gibt es Fehler an der “richtigen” Stelle, helfen die besten Sicherheitsmaßnahmen nichts.

Ich werde den Fehler natürlich umgehend an unser Technikteam in der *** Zentrale weiterleiten, aber ob und wann dort die Ressourcen zugeteilt werden um diesen Fehler zu beheben…

Den, den ich da angeschrieben habe, war nicht das Hotel um die Ecke oder ein Shop mit fünf Artikeln im System, es ist eine sehr bekannte Publikation die sich mit dem Thema IT-Sicherheit beschäftigt, also musste ich einfach noch einmal Antworten:

ich muss gestehen, Sie haben mich mit Ihrer Antwort verblüfft.

Bei einer Publikation die sich primär dem Thema IT-Sicherheit zuwendet, hatte ich nicht erwartet, dass es bei der Fehlerbehebung um das “ob” geht. :O)

Die Lücke ist nicht schwer zu finden, das heißt: Jedes Scriptkiddie kann sich als großer Hacker aufspielen, um an der Reputation von *** zu kratzen.

Der Cookie-Flag HttpOnly ist nicht gesetzt, weshalb der Session-Cookie per XSS ausgelesen werden kann. Die Session-ID ist nicht an die IP-Adresse des Benutzers gebunden. Das Fehlen dieser beiden Sicherungen, macht es einem Angreifer sehr leicht, per XSS in einen Benutzeraccount einzubrechen.

Das Session-Handling ist komplett fehlerhaft. Beim Übergang von http zu https wird die Session nicht gewechselt, was das Login per https (wegen der fehlenden IP-Bindung) ad absurdum führt. Es fehlt natürlich auch der Cookie-Flag Secure.

Die gleiche XSS-Lücke findet sich auch in den folgenden Seiten:
***.de
***.de
***.de
***.de
***.de

Am nächsten Tag war die XSS-Lücke dann schon gefixt, also hat jemand sehr schnell die “Ressourcen zugeteilt”. Aber die anderen Probleme bestehen weiterhin und es ist so gut wie sicher, dass es in der Seite irgendwo weitere XSS-Lücken gibt.

Das Login, wie es sein sollte per https:

Das Editieren im Benutzeraccount sollte aber auf gar keinen Fall unverschlüsselt erfolgen. Hier der Request bei der Änderung des Passwortes:

Das “Technikteam” weiß nicht so recht warum https verwendet wird. Sie haben wohl mal gehört dass man dieses komische SSL für Logins benutzen sollte, aber warum das gut sein soll? “Keine Ahnung, schadet ja nicht.” Anders ist es nicht zu erklären, warum es nur beim Login eine Verschlüsselung gibt.

Warum wird denn die Kommunikation zwischen Server und Client verschlüsselt?

Ohne Verschlüsselung sind Web-Daten für jeden, der Zugang zum entsprechenden Netz hat, als Klartext lesbar. Mit der zunehmenden Verbreitung von Funkverbindungen, die etwa an WLAN-Hotspots häufig unverschlüsselt ablaufen, nimmt die Bedeutung von HTTPS zu, da hiermit die Inhalte unabhängig vom Netz verschlüsselt werden.

Besser könnte ich es nicht in Worte fassen, deshalb als Zitat aus Wikipedia.
Quelle: http://de.wikipedia.org/wiki/Https

Die Cookie-Flags HttpOnly und Secure werden für den entscheidenden Session-Cookie nicht gesetzt:

Der gesetzte HttpOnly-Flag würde dafür sorgen, dass der Inhalt der Cookies nicht per JavaScript (XSS) ausgelesen werden kann. Liebes “Technikteam”, dies macht ein Angreifer natürlich NICHT per alert(document.cookie), sondern so, dass das Opfer dies nicht bemerkt.

Der gesetzte Secure-Flag würde dafür sorgen, dass Cookies nur per https übertragen werden. Auch ein Man-in-the-middle könnte die Cookies nicht im Klartext lesen, womit diese unbrauchbar wären.

Das was das “Technikteam” da gebastelt hat, ist so unsagbar schlecht, dass in der “Zentrale” sofort einige Stellen neu besetzt werden müssten.


Wie man nur mit einer Session-ID bewaffnet in ein Benutzerkonto einbricht zeigt dies kurze Video:

Das Formular nimmt die Session-ID auf, generiert eine URL inkl. Cross-Site Scripting, welche an die anfällige Website geschickt wird. Die Injektion setzt einfach den Cookie für die Session-ID und leitet dann zur Profilseite des Opfers weiter, sehr einfach, deshalb sieht man in dem Video auch nicht viel. :O)

Die XSS-Lücke in Bebo ist nicht neu, die Verantwortlichen kümmert’s nur nicht, wohl weil es Benutzer sind, die nicht direkt Geld bezahlen.
http://xssed.com/mirror/67289/

Date submitted: 17/06/2010
Date published: 18/06/2010

Update: 01.02.2012 – 18:13 Uhr

Der Session-Cookie hat einen HttpOnly-Flag spendiert bekommen:



Noch ein Link passend zum Thema XSS und HttpOnly:
“Apache httpOnly Cookie Disclosure” (fd.the-wildcat.de)


Update: 01.02.2012 – 22:00 Uhr

Wie ich schon erwartete, habe ich eine weitere XSS-Lücke gefunden, aber Dank des HttpOnly-Flags kann nun der Session-Cookie nicht ausgelesen werden.
(Weil es kein Apache ist.)

In diesem Beispiel sollen die Zugangsdaten ausgelesen werden, daher wird einfach nach ‘pass’ in der Datenbank gesucht. Hier werden die Hochkommata nicht so einfach übernommen, weshalb die Anfrage in Hexcode umgewandelt wird. Es gibt drei Tabellen in denen offensichtlich Passworte gespeichert werden: login, login_secured und users. In der Tabelle login wir nun nach den Bezeichnungen der Tabellenspalten gesucht, um im letzten Schritt die Zugangsdaten auslesen zu können: Das meistbenutzte Passwort ever!

Das Passwort wird hier im Klartext in der Datenbank gespeichert. Meist wird man aber einen Hash (MD5, SHA1) finden, für den man dann noch die Entsprechung, also das Passwort, herausfinden muss. Dank fehlendem Salt und einfachen Passworten, ist auch dies meist relativ schnell erledigt.

Mit den richtigen Werkzeugen lässt sich dies alles auch bewerkstelligen ohne zu verstehen was SQL ist — am Ende fallen nur die Zugangsdaten aus dem Tool.

In dem Beispiel wurden Daten nur ausgelesen, es ist natürlich auch möglich diese zu ändern, zu löschen oder komplett neue Datensätze hinzuzufügen.

Abhängig davon wie ein Angreifer vorgeht, wird der Seitenbetreiber nichts von dem Angriff mitbekommen. Erst wenn tausende von Kundendaten abgeflossen sind, diese missbraucht wurden, Kunden eindeutig feststellen können “Nur Shop-X hat meine Daten.” und sich beschweren, erst dann wird der Seitenbetreiber aufmerksam.

Wie man sieht, ist ein Angriff per SQL-Injection sehr einfach durchzuführen. Auch minderbegabte Scriptkiddies können hier großen Schaden anrichten, weshalb es mich immer wieder wundert, wie ignorant und leichtfertig Seitenbetreiber mit entsprechenden Hinweisen umgehen. Wenn dann mal wirklich eine Reaktion auf eine meiner Hinweise kommt, dann wird auch nur darauf geschaut, dass genau mein Beispiel nicht mehr funktioniert, dass aber an vielen anderen Stellen die gleiche Lücke besteht, wird außer Acht gelassen. Es wird immer nur an den schlimmsten Bugs geflickt und auch nur wenn man befürchten muss, dass dies öffentlich wird.


Ich habe noch immer die Hoffnung, dass es irgendwann eine Stelle gibt, denen man Sicherheitslücken melden kann und die, mit den richtigen Sanktionsmitteln ausgestattet, sich mit dem Seitenbetreiber auseinandersetzen und am Ende dafür sorgen können, dass die Lücke oder die Website geschlossen wird.


Die verfremdeten Screenshots gehören nicht zu dem ignoranten Seitenbetreiber. Es gibt so viel Unrat im Netz, da fand ich schnell eine Seite für mein Beispiel.

Die eigentlich aufgelösten AnonyPwnies – eine Splittergruppe des Onlinekollektivs Anonymous – wollen es noch einmal wissen und veröffentlichen einen letzten Leak. Dieser betrifft die Die Firma “appia.com”, die Shoplösungen für Smartphone-Software programmiert. Diese Shoplösungen weisen offenbar erhebliche Sicherheitslücken auf und ermöglichten den Pwnies das Kopieren großer Mengen sensibler Daten.

“LEAKS NEED THIS MUCH VOLUME – BY: ANONYPWNIES” http://pastebin.com/1HkZxwS4

2 Wochen lang blieb eine Reaktion auf eine SQL-Injection aus:

http://www.sicherheit-online.org/Aktuelle-Themen/Sicherheitslucke-bei-mobile2day.de-wird-ignoriert.html

Als wir das lasen, entschieden wir uns selbst nach der Lücke zu suchen und kamen mit 40GB SQL Backups, 2 GB PHP Scripten, 2 Rootserver Passwörtern, 2 Paypal Accounts und rund 100 GB Android/Windows Mobile/Symbian Apps zurück…

…nicht mit einem Erfolg zu verzeichnen.

Bitte was? “von Erfolg gekrönt” heißt es.

Wir bedauern, dass es zu diesen Übergriffen kommen musste.

Es musste nicht, aber wer Skriptkiddies Dreck in die Hand drückt, darf sich nicht wundern, wenn damit auch geworfen wird.

Der Verlauf vom ersten Hinweis bis zum heutigen Tag aber, zeugte mehr von Imkompetenz und Ingoranz, sowie von unprofessioneller Hinhaltetechnik von…

sicherheit-online.org ist inkompetent? Dies sehe ich genau so. Übrigens heißt es “Hinhaltetaktik”.

In dieser Nachricht wurde behauptet, dass keine Warnmeldung von Sicherheit-Online dort angekommen sei.

Wenn keine Bestätigung des Empfangs einer E-Mail versendet wurde, ist es nicht möglich, zweifelsfrei festzustellen, ob eine E-Mail empfangen und gar gelesen wurde.

Man wollte uns die Schuld daran geben, dass diverse “Scans” auf das Portal erfolgten und man behauptete, dass wir mit unserem Beitrag einen 0day Exploit veröffentlicht haben.

sicherheit-online.org hat die Schuld, wenn nun Kundendaten verbreitet werden und finanzielle Schäden bei den Kunden eintreten.

Zudem haben wir darauf hingewiesen, dass der Beitrag – sofern es keine Reaktion mehr geben sollte – wieder online geschalten und ein entsprechendes Update veröffentlicht wird.

Mit anderen Worte: Es wurde versucht eine Reaktion zu erzwingen, um nicht zu sagen, zu erpressen.

Die Verantwortlichen bei

sicherheit-online.org

sollten sich für den Vorgang – ernsthaft – schämen.

Dem ist nichts hinzuzfügen.

Uns trifft hier sicherlich keine Schuld, zumal ein Kontaktversuch stattgefunden hat.

Doch! sicherheit-online.org trifft die Schuld, dass die Skriptkiddys die Büchse öffneten, Daten kopierten und diese nun veröffentlichen werden. Wenn einem eine Lücke und die Schließung dieser wichtig ist, dann greift man auch mal zum Telefon, wenn per E-Mail keine Reaktion zu erhalten ist.

Wir möchten an dieser Stelle die “AnonyPwnies” bitten, Abstand davon zu halten, Kundendaten zu veröffentlichen…

Was für ein lächerlicher Appell. Und, im Straßenverkehr sollte man Abstand halten, ansonsten wird von einer Aussage oder Handlung Abstand genommen.

Deutscher Bundestag
Stenografischer Bericht 132. Sitzung Berlin, Mittwoch, den 19. Oktober 2011
http://dipbt.bundestag.de/dip21/btp/17/17132.pdf

Burkhard Lischka (SPD):
Herr Staatssekretär, wie bewerten Sie denn die Aussage eines Beamten Ihres Hauses heute Morgen im Rechtsausschuss, dass ohne Kenntnis des Quellcodes keine komplette Prüfung der Software möglich sei und vor allen Dingen keine Aussage darüber möglich sei, ob in der Software weitere Funktionen vorhanden sind, die nicht aktiviert wurden, oder ob solche Funktionen fehlen?

Dr. Ole Schröder, Parl. Staatssekretär beim Bundesminister des Innern:
Diese Aussage – ich war ja heute, anders als Sie, im Innenausschuss dabei – ist so nicht gemacht worden. Das BKA hat klargestellt, dass selbstverständlich das BKA volle Kontrolle über die Anwendung der Software hat und deshalb das Ganze rechtmäßig abläuft.

Noch einmal: Das Ganze wird auch über eine revisionssichere Protokollierung festgehalten, damit im Nachhinein überprüft werden kann, ob unter Umständen etwas eingesetzt wurde, was vom Richter nicht angeordnet worden war.

Anwesend zu sein reicht aber offensichtlich nicht aus — zuhören und verstehen wäre auch ganz hilfreich.

Jerzy Montag (BÜNDNIS 90/DIE GRÜNEN):
Herr Staatssekretär, ich muss Ihnen vorhalten, dass genau das, was Sie jetzt bestreiten, uns der Vertreter Ihres Hauses im Rechtsausschuss gesagt hat: Erstens. Wir haben keinen Quellcode. Zweitens. Ohne den Quellcode ist eine vollständige Kontrolle nicht möglich.

Ich halte es, ehrlich gesagt, auch für putzig, dass Sie uns hier erklären, das Bundesinnenministerium und die Bundesbehörden könnten diese Trojaner vollständig prüfen; denn der Chaos Computer Club habe es ohne Quellcode auch gekonnt. Das ist eine Antwort mit Chuzpe, aber so kann man, finde ich, Abgeordnete nicht abspeisen. Der Chaos Computer Club hat ja selbst geschrieben, dass er nur eine oberflächliche Prüfung durchführen kann. Dass er dabei so viel herausgefunden hat – so hat er geschrieben –, ist nur deswegen möglich gewesen, weil dieser Trojaner so miserabel gebaut worden ist.

Deswegen in allem Ernst meine Frage an Sie: Halten Sie es für richtig, rechtsstaatlich und möglich, dass staatliche Behörden auf Bundesebene einer privaten Firma gegen Geld den Auftrag erteilen, eine solche Software zu entwickeln, sich aber damit begnügen, dass sie von der Firma keinen Quellcode bekommen und damit eine vollständige Prüfung aller möglicherweise versteckten Funktionalitäten gar nicht vornehmen können?

Dr. Ole Schröder, Parl. Staatssekretär beim Bundesminister des Innern:
Entscheidend ist, welche Software im konkreten Fall angewendet wird. Das ist der rechtsstaatliche Maßstab. Das wird durch eine revisionssichere Protokollierung sichergestellt.
(Jerzy Montag [BÜNDNIS 90/DIE GRÜNEN]: Das Verfassungsgericht sieht das ganz anders!)
Wenn der Richter anordnet, dass nur die entsprechende Telekommunikation überwacht werden darf, dann darf auch nur dieses Mittel angewendet werden, und das wird durch die revisionssichere Protokollierung sichergestellt.

Sie unterstellen hier den Beamten, dass sie rechtswidrig gehandelt haben, und Sie tun das, ohne dass Sie dafür Anhaltspunkte haben. Das ist nicht in Ordnung.

Mehrfach wurde von Parlamentariern nachgefragt, ob der Quellcode von Staatstrojanern vorliegt und mehrfach meinte der Parlamentarische Staatssekretär beim Bundesminister des Innern, Dr. Ole Schröder, dass es nicht nötig sei diesen zu kennen, da man ja die “revisionssichere Protokollierung” hätte, die besagt welche Software eingesetzt wird (allerdings ohne zu wissen was sie kann). Hier weiß der Herr Staatssekretär natürlich sehr viel mehr, als Beamte (des BMI, BKA oder BSI) die im Rechtsausschuss behaupten “dass ohne Kenntnis des Quellcodes keine komplette Prüfung der Software möglich sei”.

Das BKA und die LKAs beschäftigen so kompetente Reengineerer (das BSI hat jegliche Tätigkeiten im Bereich Staatstrojaner abgelehnt), dass die am Binärcode sofort sehen können, welche 0 und welche 1 was macht. Die Bugs in dem Staatstrojaner die der CCC seziert hat, wurden dabei wohl einfach übersehen — dies kann jeder 0 mal passieren. ;O)

Die Dummheit muss offensichtlich sehr fortgeschritten sein, um das Amt eines Staatssekretärs bekleiden zu können. Ein Hirn wäre da nur hinderlich, wenn wieder und wieder der Schwachsinn repetiert wird, welcher der Dienstherr gerne verbreitet haben möchte.


Einerseits halte ich Politiker (ab einer höheren Position) generell für korrumpiert, weil, wer an wichtigen Schaltstellen der Macht angelangt ist, hat dafür seine Seele verkauft, ist Kompromisse eingegangen, die ein moralisch einwandfreier Charakter nicht in Betracht zieht, aber andererseits hege ich doch auch eine gewisse Bewunderung, wenn ich sehe wie schwer es ist, ehrlich gegen Dummheit, Lüge und Vetternwirtschaft unter den Kollegen vorzugehen.


Update: 17:28 Uhr

Der Link zu der Auflistung zu den Videos aus der Mediathek des Bundestages zur Fragestunde:
http://forum.gleitz.info/showthread.php?25965-Artikel-zu-allgemeinen-Themen/page167

Die Landesbehörden haben völlig zu Recht darauf hingewiesen, dass sie die Grenzen dessen, was rechtlich zulässig ist, nicht überschritten haben.

“Landgericht: LKA Bayern setzt rechtswidrig Screenshot-Trojaner ein” (ijure.org)

Alle dreißig Sekunden, so Rechtsanwalt Schladt, hat die staatliche Überwachungs-Software ein Bildschirmfoto des Browser-Inhalts geschossen und die Screenshots heimlich über das Internet an die Ermittlungsbehörden übertragen – zu Unrecht, wie jetzt das Landgericht Landshut festgestellt hat

Die Anordnung, auf deren Grundlage der Trojaner installiert wurde:
http://ijure.org/wp/wp-content/uploads/2011/01/AG_Landhut_Anordnung-TKUe.pdf

Unzulässig sind die Durchsuchung eines Computers nach bestimmten auf diesem gespeicherten Daten sowie das Kopieren und Übertragen von Daten von einem Computer, die nicht die Telekommunikation des Beschuldigten über das Internet mittels Voice-over-IP betreffen. Auch das Abhören von Gesprächen, die außerhalb eines Telekommunikationsvorgangs im Sinne des § 100 a StPO erfolgen, ist unzulässig.

Der Beschluss, der den Rechtsbruch feststellt:
http://ijure.org/wp/wp-content/uploads/2011/01/LG_Landshut_4_Qs_346-10.pdf

Es wird festgestellt, dass der Vollzug des Beschlusses des Amtsgerichts Landshut vom 02.04.2009 rechtswidrig war, soweit grafische Bildschirminhalte (Screenshots) kopiert und gespeichert wurden.

Was versteht das Männlein im Bundesinnenministerium daran nicht?

Die Überwachung von Voice-over-IP war erlaubt, aber alle 30 Sekunden einen Screenshot nachhause senden, definitiv nicht! Um dies zu verstehen muss man kein Jurist sein. Das Männlein ist aber Jurist, inkl. zweites juristisches Staatsexamen und Promotion an der Universität Augsburg zum Dr. jur. Ich glaube GuttenPlag sollte sich mal seine Arbeit genau ansehen. Wer einfache, leicht verständliche Sätze nicht kapiert, der kann unmöglich Jurist sein.

Das Männlein ist schlimmer und dümmer als Kanther, Schily und Schäuble zusammen. Das Männlein gehört gefeuert, mit Schimpf und Schande vom Hof getrieben, und dies ohne üppige Pensionsansprüche!

Kein Bundesinnenministers vor ihm, hat das Amt so unwürdig bekleidet wie er.

BMI-Männlein bitte geh, du bist einfach nur unerträglich.

Der Chaos Computer Club (CCC) hat eine eingehende Analyse staatlicher Spionagesoftware vorgenommen. Die untersuchten Trojaner können nicht nur höchst intime Daten ausleiten, sondern bieten auch eine Fernsteuerungsfunktion zum Nachladen und Ausführen beliebiger weiterer Schadsoftware. Aufgrund von groben Design- und Implementierungsfehlern entstehen außerdem eklatante Sicherheitslücken in den infiltrierten Rechnern, die auch Dritte ausnutzen können.

Nicht nur wegen des “0zapftis” vermute ich, dass es sich um einen Landestrojaner handelt. In “Teurer Spaß mit Bayerntrojaner” hatte ich 2008 kurz über die bayerische Version eines Trojaners und DigiTask geschrieben. Das PDF welches der CCC damals veröffentlicht hatte, fand ich nun bei den Piraten wieder: http://wiki.piratenpartei.de/images/5/54/Bayern-skype-tkue.pdf

Mich wundert dieser Bruch des Grundgesetzes durch Staatsbedienstete in keinster Weise. Das was technisch möglich ist, wird auch umgesetzt. Die dilettantische Umsetzung wundert mich ebenfalls nicht. Gute Software kostet gutes Geld und das haben die Behörden nicht. Bin ich desillusioniert was das Vertrauen zum Staat angeht? Nein, auch dort arbeiten nur Menschen und mit deren Dummheit muss man immer rechnen, wie auch im täglichen privaten oder beruflichen Leben.

Auch wenn das BKA und das Bundesinnenministerium behaupten, der Trojaner wäre nicht von ihnen, so bin ich davon überzeugt, dass sie genau wissen was in Landeskriminalämtern zum Einsatz kommt und welche Süppchen die Landesinnenministerien im Verborgenen kochen.


Hier noch ein Video, welches relativ einfach erklärt, was dem CCC zugespielt wurde:

Die IT-Sicherheit auf der Website der deutschen Bundeswehr ist offenbar mangelhaft. Zahlreiche sensible PDF-Dokumente, darunter Telefon-Listen und interne Strategie-Papiere, können über eine einfache Google-Suche mit den richtigen Parametern gefunden werden.

Naja, nur weil “VERSCHLUSSSACHE – NUR FÜR DEN DIENSTGEBRAUCH”, “VS – NUR FÜR DEN DIENSTGEBRAUCH” oder “VS – NfD” dransteht, muss der Inhalt nicht wirklich spannend sein. Manchmal wird der Stempel bzw. der Hinweis wohl auch einfach nur der Gewohnheit wegen draufgehauen. Nun werden wieder Horden von Google-Hackern nach geheimen Unterlagen suchen — und enttäuscht werden. :O)


Eine Suche nach site:bund.de ext:pdf dienstgebrauch spuckt u.a. auch folgendes aus:

[PDF] Cyber-Sicherheit in Deutschland (bsi.bund.de)
Auf Seite 3 des PDFs gibt es aber nur ein Bild zu sehen. Was hat Google denn da indexiert?


Schaut man sich die Seite genauer an und verschiebt das Bild etwas…

so sieht man was Google da gefunden hat.


Ein schon klassischer Fehler den man immer wieder findet. Ein altes Dokument wird recycelt, ohne dabei zu bedenken welche Daten unsichtbar weiterverwendet werden.

Dass dem “Bundesamt für Sicherheit in der Informationstechnik” auch solche Fehler unterlaufen ist schon fast wieder beruhigend. Die Schlapphüte vom BND hingegen, sind so paranoid, dass sie sogar ein Stellengesuch für eine “Küchenhilfs- und Reinigungskraft” (bnd.bund.de) als Verschlusssache deklarieren. :O)

Laut einer Allensbach-Umfrage sind
15 Prozent der Unternehmen “häufig” das Ziel solcher Attacken,
20 Prozent “gelegentlich” und
29 Prozent “selten”…

Dass die restlichen 36% keine Attacken festgestellt haben, bedeutet natürlich nicht, dass es keinen Angriff bei ihnen gab.


Vor ein paar Tagen schlug hier die folgende Suchanfrage auf:

bekommen seitenbetreiber sql injection mit?

Ob ein Seitenbetreiber von einem Angriff via SQL-Injection Kenntnis erlangt, hängt davon ab welches Ziel der Angreifer verfolgt.

Automatisierte SQL-Injections werden i.d.R. sehr schnell erkannt, weil bei der Darstellung der betroffenen Seiten Änderungen erkennbar sind. Es tauchen Fehlermeldungen auf, nach dem Aufruf der Seite folgt eine Weiterleitung auf anderer Seiten oder dem Besucher wird ein angeblicher Virenbefall (Fake-AV) des eigenen Computers gemeldet.

Geht es dem Angreifer hingegen um die Gewinnung von Kundendaten, wie z.B. Kreditkartendaten, so wird nur das eigentliche Opfer, der Kreditkartenbesitzer, von dem Missbrauch etwas bemerken. Der Seitenbetreiber wird erst etwas von dem Einbruch erfahren, wenn sich vermehrt Kunden beschweren, dass die Kreditkarte unberechtigt belastet wurde. Geht der Angreifer hier mit Bedacht vor, so wird das Opfer kaum vermuten können, über welchen Shop seine Daten abgeflossen sind, sofern er nicht monogam nur einem Shop vertraut.

Da in sehr vielen Systemen noch immer ungesalzene Hashes von Passworten gespeichert werden oder diese gar im Klartext vorliegen, kann ein Angriff auch das Ziel verfolgen, Zugang zum E-Mail-Konto, Paypal, eBay, etc. des Opfers zu erlangen. Erkannte Passworte aus einem Shop sind meist auch für andere Dienste die der Kunde benutzt gültig, da Passworte sehr oft mehrfach vergeben werden. Auch hier wird der Seitenbetreiber sehr wahrscheinlich nie bemerken, dass er für den Missbrauch des E-Mail-Kontos, etc. seines Kunden verantwortlich ist.


Zum Teil ist es auch ohne SQL-Injection möglich auf fremde Datenbanken bzw. der darin gespeicherten Daten zuzugreifen.

Eine Googlesuche beispielsweise nach phpMyAdmin (Administrationsoberfläche von MySQL-Datenbanken), fördert unzählige ungeschützte Datenbanken zutage. In den Suchergebnissen findet man auch Shopsysteme und darin natürlich auch wieder Kundendaten. Auch über eine Suche nach SQL-Dumps (Backups) kann ein Angreifer sehr leicht an vertrauliche Informationen gelangen.

Von solchen Zugriffen bemerkt der Seitenbetreiber auch wieder nichts, sofern der Angreifer nicht zu unvorsichtig mit den gewonnenen Daten umgeht.


Zum Abschluss noch ein krasses Beispiel für die grenzenlose Dummheit die im Netz immer öfter anzutreffen ist, weil jeder eine Seite ins Netz schubst, auch ohne jegliches Fachwissen.

Da betreibt jemand eine statische Website, die nur HTML benutzt, ohne dynamische vom Server generierte Inhalte und ohne Datenbank. Sein Hoster stellt ihm auch eine Datenbank inkl. phpMyAdmin zur Verfügung. Er fühlt sich sicher, weil ja alles statisch ist und ihm gesagt wurde, dass da nichts passieren kann.

Der Zugang zu phpMyAdmin ist nicht per Passwort geschützt. Da die Website nicht auf die Datenbank zugreift, scheint der fehlende Schutz unwichtig zu sein.

Mit etwas MySQL und phpMyAdmin kann ein Angreifer aber ohne Probleme selber Dateien ins System schreiben:

use mysql;
DROP TABLE IF EXISTS `temptab`;
CREATE TABLE temptab (codetab text);
INSERT INTO temptab (codetab) values ('<?php phpinfo(); ?>');
SELECT * INTO OUTFILE '/kunde/htdocs/info.php' from temptab;
DROP TABLE temptab;
FLUSH LOGS;

Je nach Konfiguration des Servers, kann ein Angreifer, auch außerhalb des Accounts der angegriffenen Website, Dateien schreiben.

Und zum Auslesen kann auch wieder MySQL genutzt werden:

LOAD DATA INFILE '/kunde/htdocs/config.php' INTO TABLE `hacker`

Wer nun glaubt, er wäre für Angreifer uninteressant, weil er keinen

Jahresumsatz von mehr als 500 Millionen Euro

hat, der wird früher oder später auch zum Opfer werden.