| M | D | M | D | F | S | S |
|---|---|---|---|---|---|---|
| « Aug | ||||||
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | |
„Don’t just shorten your URL, make it suspicious and frightening.“ 🙂
Beispielsweise diese:
Und wenn diese URL nicht funktioniert, dann vielleicht diese?
oder doch besser was harmloseres?
Passende URLs gibt’s bei http://www.shadyurl.com/. Klingt lustig, hat aber durchaus einen ernsten Hintergrund.
Eben gelesen:
Die Bedrohungssituation hat sich für viele Firmen fast unbemerkt verschoben. Die Angriffe richten sich seltener gegen ihre Web-, Mail- und DNS-Server (obwohl Webapplikationen immer noch gerne kompromittiert werden) und statt dessen verstärkt gegen Clients, die im Internet surfen. Ein Client-Exploit im Browser eines Benutzers der mit lokalen Administratorrechten surft genügt, um die Sicherheit eines kompletten Unternehmens zu gefährden.
(von Dino A. Dai Zovi)
Please Rob Me
Die Webseite Please Rob Me zeigt mir Hilfe einfacher Suchanfragen an Twitter und Foursquare die Nachrichten der Nutzer analysiert. Dabei wird nach Lokations- und Abwesenheitsmeldungen gesucht, die z.B. einem Einbrecher Hinweise geben könnten, wo ein Benutzer wohnt und wann er unterwegs ist. Damit soll u.a. auf die Gefahr von Social Networks aufmerksam gemacht werden, in denen Benutzer zu viele Informationen über sich preis geben. Und wir haben uns vor 15 Jahren über die Abwesenheitsnotizen in E-Mails aufgeregt …
Panopticlick
Panopticlick der Electronic Frontier Foundation (EFF) führt vor, wie eindeutig sich ein Browser durch Javascript und diverse Plugin-Kombinationen identifizieren lässt. Mit abgeschaltetem Javascript (NoScript sei Dank) komme ich auf 1 von ca. 32.000 Usern, mit eingeschaltetem Javascript bin ich mit meiner Plugin-Kombination eindeutig identifizierbar. Wobei ich mich frage, warum Javascript z.B. die installierten Systemfonts an den Server übermitteln muss.
Amazon EC2 Passwort-Cracker
Cloud-Dienste lassen sich nicht zur für Virenscanner oder Datenspeicherung nutzen sondern können (wenn viel Rechenleistung für wenig Geld angeboten wird) auch für Passwortcracker nutzen. Da Amazon der Rechenleistung Kosten verpasst, ergibt sich eine einfach nutzbare Metrik, um Passwort-Cracking mit echten Kosten zu versehen. David Campbell hat das tabellarisch aufbereitet. Interessant ist, dass die Passwortlänge wichtiger ist als die Passwortkomplexität. Ein 12-Zeichen Passwort nur aus Kleinbuchstaben kostet nach seiner Rechnung über 1,5 Millionen USD, ein komplexes Passwort mit Sonderzeichen aber nur 8-Zeichen Länge kostet günstige 106.000 USD. Erst mit 10-Zeichen Länge ist ein komplexes Passwort besser als ein simples 12-Zeichen Passwort.
Hat eigentlich irgendjemand nochmal was von Ultrascan KPO gehört? Das war der Laden der angeblich mit Hilfe eines manipulierten Nokia 1100, das unbedingt in Bochum gefertigt sein musste, mTANs abgefangen haben will. Seither ist aber Schweigen im Walde und die Webseite anscheinend tot?
Oder wollten die nur ihre Nokia 1100 teuer auf eBay verkaufen?
Wir sind in einer Diskussion auf folgende Überlegung gekommen:
Ich sitze an einem Windows-PC (ohne Desktop-Firewall) in einem geschützten Netz hinter der großen Firmen-Firewall. Surfen im Internet ist erlaubt. Außerdem ist auf dem Rechner hier ein SSL-VPN Client installiert, in meinem Fall Juniper Network Connect der Juniper SSL-VPN SA-Serie. Welches Produkt von welchem Hersteller verwendet wird, ist für die Fragestellung aber egal. Das Network Connect wird normalerweise gestartet, indem man auf die Anmeldeseite des SSL-VPN-Gateways geht und sich dort anmeldet. Abhängig von der Konfiguration wird der eigentliche Network Connect Client dann automatisch gestartet. Ich habe dann ein SSL-basiertes VPN von meinem Windows-PC durch die große Firmen-Firewall hindurch zu meinem Juniper Gateway.
Die klassische Diskussion ist dann, dass ich da natürlich beliebige Daten hinaus schleusen kann, weil der Juniper Gateway z.B. Uploads erlaubt und das ja SSL-verschlüsselt ist, d.h. die Firmen-Firewall nichts mehr sieht. Geschenkt.
Die interessante Frage die sich in unserer Diskussion jetzt gestellt hat geht genau anders herum:
Das würde nämlich bedeuten, ich habe dann eine IP-basierte VPN-Verbindung von diesem Webserver im Internet durch die Firmen-Firewall hindurch zum eigentlich geschützten Client im LAN und kann diesen direkt angreifen. Eine fehlende Desktop-Firewall natürlich vorausgesetzt.
Das ist eine ähnliche Frage wie mit den diversen ActiveX-Controls die sich im Browser wiederfinden. Die können im Grunde auch von einem beliebigen Webserver gestartet werden, wenn sie „safe“ sind. Und wenn dann eine Sicherheitslücke bekannt wird, muss Microsoft wie diesen Monat wieder, Killbits für ActiveX verteilen. Oder haben die Hersteller von SSL-VPN Clients ein Verfahren implementiert mit dem der Client feststellen kann, ob er mit einem unmodifizierte Gateway des Herstellers kommuniziert?
Ab und zu gibt es so Geschichten die irgendwie schwer einzuordnen sind. Beispielsweise die seltsame Geschichte des Samba Zero-Day Exploits. Ich rekapituliere mal kurz die Ereignisse:
Fr, 05.02.: Kingcope veröffentlicht einen Exploit mit dem sich via Symlink Beschränkungen auf Samba-Freigaben aufheben lassen. Dazu hat er einen Sambaclient modifiziert um diese Symlinks anlegen zu können.
Die Samba-Entwickler sind relativ schnell mit einem Advisory zur Hand, das dieses Problem erklärt.
Mo, 08.02.: Paul Szabo weist den Fehler zurück es handle sich um eine Fehlkonfiguration wenn diese Symlinks vom Sambadienst berücksichtigt werden.
Und dann driftet die Diskussion in das Verhalten von SMB auf Windows 2008 ab:
Ende der Diskussion. Was praktisch nicht zur Sprache kommt ist, ob z.B. die Defaultkonfiguration von Samba einfach schlecht ist und nicht das erwartet, was der typische Administrator erwartet. Zumindest kann man nicht von „Safe Defaults“ sprechen. Aber wenigstens soll die Standardeinstellung in der nächsten Version behoben werden:
Und daraus kann man eine recht einfache Lehre ziehen. Wenn ein Programm in einer Konfiguration Defaulteinstellungen vornimmt, müssen diese der Erwartungshaltung der Administratoren entsprechen. Alles andere ist genauso ein Sicherheitsrisiko wie wenn es sich bei diesem Fehler um einen echten Zero-Day Exploit gehandelt hätte. Erstaunlich ist meiner Ansicht nach, dass es immer noch so viele Programme gibt, die sich nicht an diese Regel halten.
Ein paar Sachen die schon seit geraumer Zeit in meiner Inbox vorsichhinschimmeln:
ADS
ADS is where some file metadata is stored. Yes, it’s not viewable in Windows Explorer, but if you want more transparency with ADS, you can add ADS to the Properties tabs of the file system and view ADS for every file in the GUI by using StrmExt.dll. See: http://msdn.microsoft.com/en-us/library/ms810604.aspx
Shellcode
If you are interested in shellcoding then check out www.projectshellcode.com for heaps of shellcode tutorials, whitepapers, tools and resources.
Metasploit Addon
MetaScanner is a script in ruby to scan a host for exploits than are already in metasploit framework. This is not a vulnerability scanner and may report some few false puritives. How many times have you scanned a host using nmap and then tried different exploits from the framework? This tool automates that for you. You can find it on http://kalgecin.110mb.com/index.php?id=codes.
Fuzzer
Krakow Labs maintains a current list of security driven fuzzing technologies: http://www.krakowlabs.com/lof.html
Ich denke ich werde in Zukunft öfter Links mit so einer Kurzbeschreibung für Sachen posten, die bisher unter den Tisch gefallen sind, weil sie eigentlich keinen kompletten Blogeintrag rechtfertigen.
Das kennen wir doch schon: Auf seriösen Webseiten werden nichtsahnende Benutzer durch bösartige Werbung mit Schadprogrammen infiziert. Dieses mal waren u.a. Golem.de, Zeit.de und Handelsblatt.de betroffen. Davor gerne auch mal Heise, die New York Times, The Register und andere.
Die Ursache für dieses wiederkehrende Problem findet sich an zwei Stellen:
Als Lösung für den Anwender lässt sich meiner Ansicht nach nur empfehlen, Werbung so konsequent wie möglich auszublenden und gar nicht erst zu laden. Adblock Plus im Firefox erledigt das recht zufriedenstellend und ist einfach genug auch für weniger technisch versierte Benutzer bedienbar. Leider können es sich die etablierten werbefinanzierten Online-Medien schlecht leisten, Werbeblocker zu empfehlen. Statt dessen gibt es bei Heise nur eine Anleitung wie man die unerwünschte Scareware wieder los wird. Wenn das Kind also erst einmal in den Brunnen gefallen ist.
Nur ein Link: http://extraexploit.blogspot.com/. Kommt in meine Blogroll.
Hach ja, SSL ist ein lustiger Dienst. Da braucht man so Zertifikate (X.509v3 ist recht beliebt) nur um dann feststellen zu können, die Webseite www.commerzbank.de gehört wirklich der Commerzbank in Frankfurt.
Wobei, wieso wirklich? Im Fall der Commerzbank bestätigt mir das die TC Trustcenter GmbH in Hamburg, seit neuestem eine Tochter der PGP Corp. Mein Mozilla Firefox (3.0.x) zeigt mir das in blauer Farbe vor der URL. Die Frage ist jetzt natürlich, ob ich TC Trustcenter glaube. Also quasi ob ich denen vertraue, dass sie die Prüfung korrekt durchgeführt haben und mich nicht belügen. Ich persönlich halte TC Trustcenter für recht seriös seit sie mal ein Zertifikat von mir nicht signieren wollten, das zugegeben geringfügig phishy aussah.
Wenn ich bei Verisign schaue, dem vermutlich weltweit wichtigsten Zertifikatsanbieter, bekomme ich sogar einen grünen Balken in meinem Firefox. Grün! Viel besser als blau! Weil Verisign hat sogar ein „Extended Validation“-Zertifikat. Übrigens von Verisign selbst ausgestellt. Die bescheinigen sich also selbst, dass sie Verisign sind. Das Extended Validation Zertifikat ist meiner Ansicht nach ja Beutelschneiderei par Excellenz. Da verlangt Verisign doppelt so viel Geld für das Zertifikat nur um den Antragsteller „genauer“ zu prüfen als für weniger Geld. Als ob eine vertrauenswürdige Zertifizierungsstelle nicht sowieso genau prüfen sollte. Aber gut, von Verisign kann man vermutlich nichts anderes erwarten. Die haben auch schon mal ohne Prüfung Zertifikate auf den Namen Microsoft ausgestellt. (Die sind übrigens immer noch im Internet Explorer als „Fraudulent“ zu finden). Außerdem war Verisign bis Oktober 2008 Haupteigentümer von Jamba. Das ist die Firma, die kleine Kinder mit Klingeltonabos über den Tisch zieht. Ob ich die wirklich vertrauenswürdig finde … ich bin mir da gar nicht so sicher. Verisign wäre jedenfalls der letzte Anbieter bei dem ich ein Zertifikat kaufen würde.
Der Chaos Computer Club greift übrigens auf die Dienste von CACert zurück. Die kennt mein Firefox nicht, und der Internet Explorer erst recht nicht. Obwohl ich die für recht vertrauenswürdig halte. Beim IE ist das aber klar. Ich habe mir sagen lassen, dass Microsoft rund 50.000 USD will, damit eine Zertifizierungsstelle in den IE aufgenommen wird. Und da CACert die Zertifikate kostenlos anbietet, vertragen sich die beiden Geschäftsmodelle recht schlecht. Vertrauen hin oder her.
Über die lustigeren Zertifizierungsstellen will ich gar nicht lästern, auch wenn mir ein Zertifikat einer deutschen Onlinebank ausgestellt z.B. vom „Autoridad Certificadora del Colegio Nacional de Correduria Publica Mexicana“ etwas … naja, spanisch … vorkommen würde. Obwohl die laut Internet Explorer sicher sehr vertrauenswürdig sind. Leider ist deren Zertifikat Mitte 2009 abgelaufen. Aber es gibt ja auch noch die „Saunalahden Server CA“ aus … na? … genau, Finnland. Wo soll so ein Saunala(h)den auch sonst herkommen 😉
Warum ich das alles schreibe? Weil es bei SSL-Zertifikaten eben einfach nur um das Vertrauen zum Aussteller geht. Ist die Zertifizierungsstelle (CA) vertrauenswürdig? Stellt sie nur Zertifikate aus wenn die Identität korrekt verifiziert worden ist? Oder kann jeder dahergerollte Schäuble zu so einer CA gehen und ein falsches Zertifikat bekommen um einen staatlichen Man-in-the-Middle Angriff durchzuführen? Dann will ich so eine CA gar nicht im Browser haben.
Die Mozilla Foundation hat sich genau diese Diskussion nämlich jetzt eingefangen, nachdem die staatlich kontrollierte chinesische Domainregistry CNNIC mit ihrer Zertifizierungsstelle in den Firefox-Browser aufgenommen wurde. Dabei wurden die Anforderungen der Mozilla Foundation strikt erfüllt. CNNIC hat eine Zertifikatspolicy (CSP) die formal allen Anforderungen genügt. Meine Freunde von Ernst & Young haben geprüft, dass diese Policy formal ok ist. Webtrust hat gekuckt, dass Ernst & Young formal korrekt geprüft hat. Und die Mozilla Foundation verlässt sich darauf, dass die Anforderungen von Webtrust formal korrekt sind. Formal eben. Nur das mit dem Vertrauen, das ist halt schwierig.
Aber wenn mich jemand fragt … das Sicherheitsmodell von SSL ist sowieso für’n Arsch.
(via Fefe)
Nachtrag:
Die Mozilla Foundation hat die CNNIC-SSL-Zertifikate wieder aus der Standardinstallation entfernt.