Web-Sicherheit

März 30, 2011

Zurücksetzten von Passwörtern in Webanwendungen

Filed under: Allgemein — sebastiankuebeck @ 08:25
Tags: , , , ,

Wenn es um die Sicherheit von Webanwendungen geht, gibt es zahlreiche weiße Flecken auf der Landkarte. Diese „unerforschten Territorien“ sind Mechanismen, die die meisten Webanwendungen besitzen, für die aber keine allgemein anerkannten, sicheren Implementierungsstrategien existieren. Ein solcher Mechanismus ist zum Beispiel jener, mit dem Benutzer ihre Passwörter zurücksetzten können, wenn sie diese vergessen haben. Er ist auch unter den Bezeichnungen Password Recovery Feature oder Forgotten Password Feature bekannt.

Der Sicherheitsberater David Ferguson hat kürzlich in einem White Paper zahlreiche gängige Implementierungen dieses Mechanismus analysiert und daraus Tipps für die eigene Implementierung abgeleitet. Generell werden zwei Arten von Mechanismen benutzt, um einen Benutzer auch ohne Passwort zu authentifizieren:

  • Zusenden des Passworts an den Benutzer über einen zweiten, möglichst unabhängigen Kanal (z.B.: E-Mail, SMS). Dabei kann auch ein Code zugeschickt werden, der dann beim Zurücksetzten in der Webanwendung eingegeben werden muss.
  • Anstatt des Passworts wird eine Frage gestellt, deren Antwort im Idealfall nur der Benutzer kennen kann und die vom Benutzer bei der Registrierung vorgegeben wird.

Leider haben beide Methoden ihre Schwächen, weshalb David Ferguson vorschlägt, diese Mechanismen sicherer zu gestalten oder intelligent zu kombinieren, damit sie keine bequeme Hintertür für Hacker darstellen.

Zusenden des Passworts oder eines Codes

David Ferguson kommt genau wie Joseph Bonneau und seine Kollegen zu dem Schluss, dass die gängige Praxis, nämlich das vergessene  Passwort per E-Mail an den Benutzer zu schicken, keine gute Idee ist. Schließlich sind diese E-Mails ja nicht verschlüsselt und so lassen sie sich relativ leicht – beispielsweise in öffentlichen WLANs – abfangen.

Der Benutzer bekommt einen Link (mit einem eingebetteten Code), dem er folgen soll, damit er sein Passwort zurücksetzten kann.
Diese E-Mail kann natürlich leicht abgefangen werden.

Diese Methode lässt sich leider nicht dadurch verbessern, dass man lediglich einen Link mit einem geheimen Code in die E-Mail aufnimmt, denn der Code kann ja ebenfalls abgefangen werden.

Stellen von Fragen, deren Antwort nur der Benutzer kennt

Wie bereits in meinem Buch erwähnt, ist es nicht besonders schlau, die Frage durch den Benutzer selbst formulieren zu lassen, denn dieser wird in vielen Fällen das Passwort selbst in leicht verschleierter Form in die Frage einbauen. Leider sind auch Antworten auf gängige Fragen – wie beispielsweise die nach dem Mädchennamen der Mutter des Benutzers – für einen Hacker leicht durch ein paar Recherechen im Internet zu ermitteln.

Die Frage nach dem Jugendfreund lässt sich üblicherweise relativ leicht ermitteln.

David Ferguson schlägt hier vor, statt einer mehrere Fragen zu stellen und diese Fragen möglichst intelligent zu wählen. goodsecurityquestions hält beispielsweise zahlreiche nützliche Tipps für diese Sicherheitsfragen bereit.

Wie bereits erwähnt, macht es durchaus Sinn, nicht nur auf einen Mechanismus zu vertrauen sondern diese zu kombinieren, beispielsweise indem man erst einmal eine E-Mail mit einem Code an den Benutzer schickt. Der Benutzer muss dann diesen Code eingeben UND eine Sicherheitsfrage beantworten, damit er sein Passwort zurücksetzten kann. Darüber hinaus kann ein CAPCHA und ein Verzögerungsmechanismus bei falschen Eingaben Brute-Force-Angriffe deutlich erschweren. Es ist allerdings auch zu beachten, dass man die Benutzer nicht durch all die Absicherungsmechanismen überfordet!

Abschließend zählt der Autor noch einige gängige DOs und DON’Ts auf, die man bei der Implementierung dieser Art von Mechanismen beachten sollte. Das könnte allerdings suggerieren, dass es einfach wäre, einen solchen Mechanismus oder generell einen sicheren Authentifizeirungsmechanismus zu implementieren. Dem ist leider nicht so!

Generell ist es praktisch unmöglich, einen sicheren Authentifizierungsmechanismus zu implementieren, das gilt natürlich auch für jeden Mechanismus zum Zurücksetzten von Passwörtern!

Die Auswahl eines geeigneten Authentifizierungsmechanismus ist daher immer ein Kompromiss, der sorgfältig auf den jeweiligen Anwendungsfall abgestimmt werden muss. Also sollte man sich erst einmal grundlegend mit der Problematik der Authentifizierung vertraut machen und lernen, wie man Authentifizierungsmechanismen angreift, bevor man einen eigenen Authentifizierungsmechanismus implementiert.

In meinem Buch wird in Kapitel 5 der Unterschied zwischen Identifizierung, Authentifizierung, Authentisierung und Autorisierung erörtert und es werden diese Begriffe im Zusammenhang mit Webanwendungen ausführlich erklärt. Das Kapitel 11 widmet sich gängigen Fehlern in der Implementierung von Authentifizierungsmechanismen und wie man diese vermeiden und gegebenenfalls beheben kann.

März 29, 2011

MySQL.com gehackt… mittels SQL Injection!

Filed under: Allgemein — sebastiankuebeck @ 06:20
Tags: , , , , , , ,

Die Seite mysql.com, welche von MySQL, – einer Tochterfirma von Oracle – betrieben wird, wurde am Wochenende Opfer eines SQL-Injection-Angriffs.

Zu dem Angriff bekannten sich die beiden romänischen Hacker TinKode und Ne0h von Slacker.Ro, die sich selbst als Gray-Hats bezeichnen, also als Hacker, die auf Sicherheitsprobleme aufmerksam machen wollen.

Sie veröffentlichten die im Zuge des Angriffs ermittelten Benutzernamen und Password-Hashes auf pastebin.com. Da diese Hashes offenbar keinen Salt-Wert verwendeten (siehe den Fall HBGary), lassen sich so die Passwörter relativ leicht mittels Regenbogentabellen ermitteln. Dabei stellte sich heraus, dass der Produktmanager für WordPress bei MySQL eine vierstellige Zahl als Passwort verwendet. Zahlreiche andere Benutzer verwendeten ‚qa‘ als Passwort.

Auch Oracle selbst wurde ein Opfer dieses Angriffs, allerdings wurden in diesem Fall keine Zugangsdaten entwendet. Das ganze wirft kein gutes Licht auf die Sicherheitspraktiken von Oracle und seinen Tochterfirmen, schließlich hat das Unternehmen Hinweise auf eine Cross-Site-Scripting-Schwachstelle in der MySQL-Homepage laut XSSed.com seit Jänner ignoriert.

März 24, 2011

Bankentrojaner für Handys

Filed under: Allgemein — sebastiankuebeck @ 11:29
Tags: , , , , ,

Im Kampf gegen Phishing-Angriffe auf das Onlinebanking werden von Banken immer wieder neue Techniken ersonnen, um ihren Kunden eine sichere Autorisierung von Transaktionen zu gewährleisten. Begonnen hat das mit TANs (Transaktionsnummern). Nachdem dieses Verfahren schnell von Autoren von Phishing-Mails ausgehebelt wurde, folgten iTANs, welche wiederum erfolgreich angegriffen wurden. Der jüngste Autorisierungsmechanismus – mTAN genannt – verwendet das Handy des Kunden, um Transaktionen zu autorisieren.

 

Beim mTAN-Verfahren bekommt der Kunde per SMS eine
Transaktionsnummer zugeschickt. Mit dieser autorisiert
er seine Transaktion auf der Onlinebanking-Seite. (Bild: Postbank)

Dieses Verfahren wurde zum ersten Mal in Australien erfolgreich angegriffen: Der Angreifer brachte den Mobilfunkanbieter dazu, die Handynummer eines Kunden auf sein eigenes Handy umzuleiten. Nun bekam der Angreifer die SMS mit der Transaktionsnummer und konnte so das Opfer dazu bringen, ihm selbst Geld zu überweisen.

Vor einiger Zeit berichtete nun der Sicherheitsdienstleister Kaspersky, wie der Trojaner ZeuS das mTAN-Verfahren aushebelt: Anlassfall waren zahlreiche Angriffe in Polen auf Kunden der ING-Bank. Im Gegensatz zu früheren ZeuS-Versionen nistet sich dieses Exemplar nicht am PC des Kunden sondern auf dessen Handy ein.

Damit ist jetzt eingetreten, wovor Sicherheitsexperten schon seit Jahren warnen: Schadsoftware verbreitet sich nun auch auf Mobiltelefonen. Laut Kaspersky attackiert ZeuS die Plattformen Windows Mobile 9 und Blackberry.

Inzwischen warnt auch das deutsche BSI for Angriffen auf das mTAN-Verfahren. Bei den Angriffen in Deutschland wird der Angriff durch eine Schadsoftware auf dem PC des Kunden eingeleitet, indem der Kunde aufgefordert wird, seine Handynummer, das Handy-Modell oder die Geräteidentifikationsnummer (IMEI) auf der Webseite des Angreifers, die natürlich der realen Seite der Bank täuschend echt nachempfunden ist, einzugeben. Nach Eingabe dieser Daten erhält der Nutzer eine SMS mit einem Link, dem er folgen soll, um ein notwendiges Zertifikat-Update zu installieren. Dahinter verbirgt sich in Wirklichkeit aber ein Spionage-Programm, dass die mTAN aus der SMS ausliest und an den Angreifer weiterleitet.

Ein erfahrener Computerbenutzer wird natürlich stutzig, wenn er nach dem Handy-Modell gefragt wird, allerdings genügt es den Angreifern, wenn nur eine geringe Anzahl an Kunden auf diesen Schwindel hereinfällt. Wir werden uns also früher oder später wohl damit abfinden müssen, auch Virenscanner auf dem Handy zu betreiben, mit all den negativen Konsequenzen (Performanceeinbußen, häufige Updates, Falschmeldungen), die wir bereits von den PCs her kennen…

März 23, 2011

Autos mittels MP3-Dateien hacken

Filed under: Allgemein — sebastiankuebeck @ 14:23
Tags: , , , ,

Diese Geschichte ist wirklich originell: Forschern der Universität von Kalifornien in San Diego ist es gelungen, mithilfe einer MP3-Datei, die auf eine CD gebrannt war, die Bordelektronik von Autos zu manipulieren (weitere Artikeln zu diesem Thema befinden sich hier und hier). Dabei genügt es, die CD mit der manipulierten MP3-Datei in der Stereoanlage abzuspielen, um so die Elektronik des Fahrzeuges zu beeinflussen. Wie Stefan Savage – einer der beteiligten Forscher – schon  vor zwei Jahren demonstrierte, ist es so zum Beispiel möglich, den Motor absterben zu lassen, die Türen zu versperren, die Bremsen zu deaktivieren oder die Tachoanzeige zu manipulieren.

Gehackter Kilometerzähler

Abgesehen von der Stereopanlage konnten sich die Forscher auch über Handy- und Bluetoothverbindungen – letztere wird beispielsweise für die Freisprecheinrichtung benutzt – in die Bordelektronik hacken. Das das auch mit dem Anschluss funktioniert, den KFZ-Mechaniker zu Diagnosezwecken verwenden, versteht sich hier fast schon von selbst. Betroffen waren die Systeme OnStar von General Motors und Sync von Ford aber  auch Enform von Lexus, Assist von BMW und Mbrace von Mercedes Benz besitzen ein eingebautes Handy und sind daher prinzipiell für solche Angriffe verwundbar.

So könnten beispielsweise Autodiebe ganz einfach Autos entwenden, indem sie sich in das gewünschte Fahrzeug hacken und so die Türen öffnen. Weiterhin wäre es damit flüchtigen Bankräubern theoretisch möglich, die Motoren der sie verfolgenden Polizeifahrzeuge abzudrehen. Auftragskiller der Mafia bräuchten die Autos ihrer Opfer nicht mehr in die Luft sprengen. Es würde genügen, die Bremsen des Wagens, in dem sich das Opfer befindet, auf einer abschüssigen Straße zu blockieren…

Sicherheitsunternehmen RSA Security gehackt

Filed under: Allgemein — sebastiankuebeck @ 08:27
Tags: , , , ,

Nachdem vor einiger Zeit das Sicherheitsunternehmen HBGary Ziel von Hackerangriffen war, hat es nun RSA Security erwischt. Im Gegensatz zu HBGary ist RSA allerdings keine lokale Größe sondern das wahrscheinlich bekannteste IT-Sicherheitsunternehmen überhaupt. Laut Angaben des Unternehmens handelte es sich um eine Serie von äußerst ausgeklügelten Angriffen, die offenbar das Ziel hatten, Informationen über das Produkt SecurID zu erhalten.

Der SecurID-Token generiert alle paar Sekunden eine Zufallszahl. Zur
Anmelden gibt man einfach diese Zahl zusammen mit einer Geheimzahl,
die man sich merken muss, an. Da keine Hardwareverbindung zwischen
Computer und Token nötig ist, lässt sich dieses Verfahren einfach in die
bestehende IT-Infrastruktur integrieren.

SecurID ist wahrscheinlich eines der populärsten Verfahren zur Umsetzung von Zwei-Faktor-Authentifizierung. Angeblich sind 40 Millionen dieser Geräte im Umlauf und würde es den Einbrechern gelungen sein, die Zahlen, die dieses Gerät produziert, vorherzusagen, hätten logischerweise alle Kunden von RSA, die dieses Produkt verwenden, ein massives Problem.

Laut dem anerkannten Sicherheitsexperten Bruce Schneier ist allerdings zur Zeit nicht klar, was genau passiert ist und welche Informationen entwendet wurden, deshalb kann man zu diesem Zeitpunkt noch nicht sagen, ob bestehende Geräte nun unsicher sind, oder nicht.  Würde es zum Schlimmsten kommen und die Angreifer könnten die Zahlen aller Geräte vorhersagen, hat RSA keine möglichkeit, die Software auf diesen Geräten auszutauschen, da diese Versiegelt sind und Firmware-Updates nicht vorgesehen sind. Bliebe RSA nur noch der Weg, alle Geräte auszutauschen, was eine enorme wirtschaftliche Belastung für das Unternehmen darstellen würde. Der Schaden ist ohnehin jetzt schon hoch, das das Unternehmen seinen Ruf als Vorzeigeunternehmen in Sachen Sicherheit erst einmal los ist.

Dieser Vorfall zeigt einmal mehr, dass es selbst den besten Sicherheitsexperten nicht möglich ist, ihre IT wirksam abzusichern. Warum das nicht möglich ist, hat Bruce Schneier kürzlich in einem Interview erklärt:

Es gibt einfach zu viele Angriffsmöglichkeiten gegen heutige IT-Systeme und wenn jemand wirklich bereit ist, unbegrenzt Zeit und Geld zu investieren, um in die IT-Systeme eines Unternehmens einzudringen, wird er irgendwann Erfolg haben.

Wir haben uns mit dieser Realität bei der physischen Sicherheit längst abgefunden und gehen laufend Kompromisse zwischen Kosten und Aufwand auf der einen und Sicherheit auf der anderen Seite ein. Bei der Informationssicherheit verhält es sich nicht anders. Die Möglichkeiten, IT-Systeme abzusichern, sind nun einmal begrenzt und daran können auch die besten Sicherheitsexperten der Welt nichts ändern.

Update vom 8.6.2011

Der schlimms mögliche Fall ist offenbar tatsächlich eingetreten: die Hacker benutzten die geklauten Informationen, um beim Rüstungskonzern Lokheed Martin einzubrechen. Nun sieht sich RSA Security gezwungen, 40 Millionen SecureID-Tokens auszutauschen.

März 18, 2011

Rezension

Filed under: Allgemein — sebastiankuebeck @ 07:20
Tags: , , , , , ,

Nette Rezension meines Buches von Mark Buzinkay. Der zweite Teil meines Buches ist in der Tat etwas anspruchsvoller, da nicht alle Angriffstechniken ganz einfach zu erklären sind. Aus den bisherigen Workshops weiß ich, dass besonders Cross-Site Request Forgery für die Teilnehmer anfangs nicht ganz leicht zu durchschauen ist. Das hängt wahrscheinlich damit zusammen, das so wenig HTML-Code notwendig ist, um sie auszunutzen.
Um das Verständnis der Angriffstechniken, die im Buch beschrieben sind, zu erleichtern, habe ich eine kleine Demoanwendung in Java entwickelt, die die Schwachstellen, die im Buch beschrieben werden, demonstriert. Sie ist auf der Seite des Verlages unter „Quelltexte“ zu finden.

Demo-Anwendung zur Demonstration von CSRF-Angriffen

Es gibt auch zahlreiche Videos im Netz (wie beispielsweise dieses), in denen das Ausnützen von Cross-Site-Request-Forgery-Schwachstellen demonstriert wird.

März 14, 2011

Hackergruppe veröffentlicht interne Korrespondenz der Bank of America

Filed under: Allgemein — sebastiankuebeck @ 17:26
Tags: , , ,

Wie bereits angekündigt, hat heute eine Hackergruppe interne E-Mails der Bank of America veröffentlicht. Es handelt sich um interne E-Mails von Angestellten der Bank of America vom November 2010. Die Verfasser scheinen Angestellter der Balboa Versicherung zu sein, einer Tochterfirma der Bank of America.

Die E-Mails beinhalten angeblich details zu illegalen Zwangsvollstreckungen, welche von Mitarbeitern der Bank of America angeordnet haben sollen. Kosumentenvereinigungen haben Banken in der Vergangenheit mehrfach bezichtigt, Zwangsvollstreckungen durchzuführen, obwohl sie ihre Ansprüche nicht ausreichend durch Dokumente belegen konnten.

Ein Sprecher der Bank of America behauptete am Sonntag, dass diese E-Mails von einem früheren Angestellten gestohlen worden seien. Sie seien rein administrativer Natur und enthielten keine Informationen über Zwangsvollstreckungen. Wörtlich sagte er: „Wir sind überzeugt davon, dass diese frei erfundenen Anschuldigungen haltlos sind.“

Die E-Mails beinhalten auch den E-Mail-Verkehr zwischen der Hackergruppe Anonymous und besagtem ehemaligen Angestellten der Bank of America. In diesen E-Mails behauptet letzterer, dass die Bank eine Art religiöser Kult sei und dass man nun seine Karriere zerstören werde. Der ehemalige Mitarbeiter schreibt in einer E-Mail: „Sie sagten, ich bin in der ganzen Bank bekannt, als sie jedem mein Bild zeigten und mich als Terrorist bezeichneten.“

Eigentlich wurde von Wikileaks angekündigt, dass interne E-Mails rund um den Bankencrash 2008 veröffentlicht werden würden. Was nun tatsächlich veröffentlicht wurde, scheint deutlich weniger spektakulär zu sein. Möglicherweise kommt da ja noch etwas nach…

Bank of America: Wir konfiszieren Immobilien, die wir gar nicht besitzen…

März 12, 2011

Massives Sicherheitsproblem bei Telekom Austria Modems

Filed under: Allgemein — sebastiankuebeck @ 09:18
Tags: , ,

In meinem gestrigen Artikel habe ich versucht, auf die Gründe einzugehen, warum SOHO-Router so unsicher sind und warum niemand etwas dagegen unternimmt.

Ein paar Stunden später veröffentlichte futurzone.at folgende Meldung:

Massives Sicherheitsproblem bei Telekom [Austria] Modems

[…] Durch eine Sicherheitslücke kann trotz WPA-Verschlüsselung problemlos in WLAN-Netzwerke von Telekom-Kunden eingedrungen werden. Sofern Kunden das von der Telekom zur Verfügung gestellte Thomson-Modem mit den Standardeinstellungen in Betrieb genommen haben. Wurden Name und Passwort nicht verändert, kann über die öffentliche Bezeichnung des Netzwerkes (SSID) der korrekte Schlüssel errechnet werden. Das dazu notwendige Tool – es ist übrigens kostenlos – findet sich im Web.

Mit anderen Worten: Die Schlüssel wurden mit einem einfachen Mechanismus aus der SSID gebildet. Nun ist der Mechanismus bekannt und so kann jeder die Zugangsdaten zu den an sich geschützten WLANs einfach ermitteln.

Der österreichische Standard schreibt weiterhin:

Betroffen sind davon nicht nur Kunden der Telekom Austria. Die Art der Schlüsselerstellung sei bis Ende 2010 gängig gewesen, heißt es seitens des Unternehmens. Sogesehen sollten alle Nutzer, die WLAN-Modems dieser Hersteller verwenden, ihre Modellnummer überprüfen. Die Telekom Austria habe die genannten Modems bis Mitte 2010 mit der WPA-Verschlüsselung als Standardeinstellung an Kunden ausgegeben. Nachdem das Unternehmen von der Sicherheitslücke in Kenntnis gesetzt wurde, habe man die Auslieferung eingestellt und die Kunden zu Jahresende davon informiert.

[…]Auf den Seiten der TA finden Kunden eine Anleitung sowie einen WLAN-Assistenten für Windows und Mac OS zum Herunterladen, mit dem sie die Einstellungen leicht ändern können.

Also ich bin seit Jahren Kunde der Telekom Austria und mich hat niemand informiert. Ich habe allerdings eine ausgeprägte, berufstbedingte Paranoia, was Standardeinstellungen betrifft…

Eines der betroffenen Geräte: Thomson TG 585 V7

März 11, 2011

Schwachstellen in SOHO-Routern

Filed under: Allgemein — sebastiankuebeck @ 16:15
Tags: , , ,

Im Herbst 2008 besuchte ich einen Vortrag zum Thema Schwachstellen in SOHO-Routern, also Router für Privatanwender und kleine Unternehmen. Im Zuge seines Vortrags schilderte Sebastian Graf im Detail, wie einfach es ist, in diese Router einzudringen um Beispielsweise Schadsoftware dort zu platzieren (das Paper dazu befindet sich auf seiner Homepage).

Schadsoftware in Routern

Verwundbarer Router Speedport v500.
Bei diesem Gerät konnte man die Authentifizierung umgehen,
und das Gerät nach belieben umkonfigurieren.
Möglicherweise funktioniert das heute noch…

Diese Schadsoftware könnte beispielsweise Cookies klauen und an den Angreifer weiterleiten. Hat sich nun der Besitzer beispielsweise bei Twitter angemeldet, könnte der Angreifer den Sitzungsschlüssel des Besitzers übernehmen und eigene Nachrichten unter dem Namen des Besitzers posten – ähnlich, wie das bei offenen WLANs mit Firesheep gelingt. Natürlich könnte er auch die Profilseite nach belieben umgestalten.

Natürlich könnte er auch alle E-Mails des Benutzers mitlesen. Damit wäre es ihm beispielsweise möglich, auf der lauer zu liegen, bis der Besitzer das Passwort von irgendeiner Webseite vergisst. Schickt der Seitenbetreiber nun eine E-Mail mit einem neuen Passwort an den Benutzer, kann der Angreifer diese E-Mail abfangen und gelang so an die Zugangsdaten des Besitzers, ohne das dieser etwas davon bemerkt!

Reaktion der Hersteller

Die Sache ist also nicht ungefährlich, weshalb Sebastian versuchte, die Hersteller dieser Router zu informieren. Zu seinem erstaunen musste er jedoch feststellen, dass sich das Interesse der Hersteller in Grenzen hielt. Es stellte sich sogar heraus, dass einige Hersteller unter ihren zahlreichen Lieferenten nicht denjenigen ausfindig machen konnten, der für die Firmware zuständig war.  Neulich fand ich in einer XING-Gruppe eine Anfrage eines Studenten, der mit einem Freund eine gravierende Schwachstelle in seinem Router gefunden hatte, was darauf schließen lässt, dass die Hersteller die Probleme immer noch nicht in den Griff bekommen haben.

Hier stellen sich natürlich zwei grundlegende Fragen:

  1. Warum reagieren die Gerätehersteller nicht?
  2. Warum hört man nie von Einbrüchen in SOHO-Router?

Wie Sie sich vielleicht denken können, enthält die zweite Frage die Antwort auf die erste, aber beginnen wir bei der ersten und damit beim Einmaleins der IT-Sicherheitsökonomie…

Warum reagieren die Gerätehersteller nicht?

Auf dem Markt für SOHO-Router tobt ein gnadenloser Preiskampf und sichere Firmware für Router zu entwickeln kostet Geld. Dieses Geld kann der Routerhersteller dem ISP aber nicht weiterverrechnen, da sich die ISPs ebenfalls in einem beinharten Preiskampf mit anderen ISPs befinden. Der ISP wiederum kann die Mehrkosten nicht an den Endkunden weiterverrechnen, denn der wechselt sofort den ISP, wenn er ein paar Cent pro Monat mehr bezahlen muss. Die Sicherheit spielt für die Entscheidung, welchen ISP der Kunde wählt, keine Rolle und das hat wiederum folgende Gründe:

  • Der Kunde kann nicht beurteilen, welcher Router sicherer ist und was ein unsicherer Router für ihn bedeutet.
  • Der Kunde ist der irrigen Meinung, dass der Gerätehersteller von Rechts wegen verpflichtet sei, sich um die Sicherheit seiner Router zu kümmern. Schließlich gibt es für alles und jedes eine EU-Richtlinie, also wird es hier auch irgend eine Regelung geben.

Im letzten Punkt irrt der Kunde: Das Gerät wird zwar geprüft, ob die Abschirmung stimmt und ob der Router bei einem Kurzschluss in Flammen aufgeht, die Software wird aber nicht auf Sicherheit gegen Hackerangriffe geschützt. Das hat wieder damit zu tun, dass SOHO-Router offenbar selten so gehackt werden, dass es einer großen Anzahl von Benutzern auffällt und solange dass nicht passiert, wird kein Politiker aktiv, den welcher Politiker will schon für die Verteuerung von Netzwerkzugängen verantwortlich sein, solange scheinbar ohnehin nichts passiert?

Warum hört man nie von Einbrüchen in SOHO-Router?

Das Folgende wurde aufgrund von berechtigten Einwänden von Herrn Hans Adams korrigiert…

Einbrüche auf SOHO-Router finden tatsächlich statt, diese Vorfälle sind bisher allerdings unterhalb der öffentlichen Wahrnehmungsschwelle geblieben. Das liegt daran, dass Angreifer meist nicht versuchen, die Router lahmzugegen oder den Betrieb zu stören, sondern die Router möglichst unbemerkt für ihre Zwecke zu missbrauchen.

Das ist natürlich nur der gegenwärtige Stand der Dinge, denn die Sicherheitssituation im Internet ändert sich rasch und Angriffe auf SOHO-Router werden von einer breiteren Öffentlichkeit wahrgenommen werden, wenn es den Hackern gelingt, mit gehackten SOHO-Routern das große Geld zu verdienen und wenn dadurch eine größere Anzahl von Geschädigten auf sich aufmerksam macht.

Wenn Sie mehr zu den ökonomischen Aspekten der IT-Sicherheit erfahren wollen empfehle ich Prof. Andersons Paper Why Information Security is Hard – An Economic Perspective. Kapitel 3 meines Buches widmet sich neben den ökonomischen auch den psychologischen Phänomenen der IT-Unsicherheit.

März 2, 2011

Aufspüren von ReDoS-Schwachstellen

Filed under: Allgemein — sebastiankuebeck @ 08:57
Tags: , , , ,

Mit ReDoS wird eine spezielle Form von Denial of Service bezeichnet, welche reguläre Ausdrücke benutzt, um Webanwendungen und andere Systeme, die reguläre Ausdrücke benutzen, lahmzulegen.

Der Hintergrund ist, dass manche regulären Ausdrücke die Bibliothek, die diese Ausführt, dazu veranlasst, enorm viel Rechenzeit für diese Ausführung zu verbraten. Das ganze funktioniert allerdings nur mit speziellen Ausdrücke und für speziell dafür angepassten Eingabedaten. So führt folgender Ausdruck mit den darauffolgenden Eingabedaten dazu, das die Ausführung „einfriert“:

(a+)+
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaX

Ich habe mich in letzter Zeit mit dem Thema näher beschäftigt und ein Werkzeugt entwickelt, mit dem man diese Schwachstellen automatisch und in vertretbarer Zeit aufspüren kann. Dazu habe ich auf meinem englischsprachigen Blog zwei Artikel verfasst, die das Verfahren beschreiben und anderen Verfahren gegenüberstellt:

Detecting and Preventing ReDoS Vulnerabilities
Detecting and Preventing ReDoS Vulnerabilities, Part 2

Bloggen auf WordPress.com.