Mitternachtshacking

Das ist fast schon so krass wie die Blackberry-Geschichte in den Vereinigten Arabischen Emiraten: Forscher von TippingPoint haben eine scheinbar nützliche Anwendung mit dem Namen “WeatherFist” auf einem Portal zum Download und zur Installation auf Mobiltelefonen angeboten. Innerhalb von wenigen Stunden haben über 700 User die Anwendung runtergeladen und installiert. Innerhalb einiger Tage waren es bereits 8000 infizierte Telefone. Neben der harmlosen Wetteranzeige hat die Anwendung nur den Standort des Telefons gemeldet, genauso einfach hätte man jedoch auch echten Schaden anrichten können. Erstaunlich, daß es bisher nicht mehr Schadanwendungen für Mobiltelefone gibt. Oder hat die nur noch niemand entdeckt?

Das Problem ist … was will man dagegen tun? Nur Anwendungen aus vertrauenswürdigen Quellen herunterladen? Aus dem iTunes Store für das iPfusch, aus dem Google Store für das Android und aus dem Ovi Store für Nokia? Und was, wenn es das benötigte da nicht gibt? Beispielsweise war Putty für das TouchUI eine der ersten Anwendungen die es auf mein neues Telefon geschafft haben. Inzwischen laufen da mehrere Tools, die nicht aus dem Ovi Store sind.

Das Problem wird sein, daß Virenscanner keine echte Chance haben, solche Anwendungen zu finden. Ja, es gibt für mein Mobiltelefon beispielsweise einen Schadcode-Scanner von Trend Micro und einen weiteren von F-Secure. Der von F-Secure ist sogar vorinstalliert. Ich wette, das hätte TippingPoint-Trojaner auch nicht erkannt. Dafür kostet der Adobe Reader 10,- Euro. Das ruft doch nur so nach infizierten Raubkopien. Und mit etwas Geschick kann man einen Trojaner immer so programmieren, daß der Virenscanner ihn nicht findet.

Lösungen? Tja, eine echte habe ich nicht. Nur signierte Anwendungen zuzulassen ist jedenfalls keine. Dann bekommt man ein Lock-in-Gerät wie mit dem iPfusch von Apple. Was ich mir für mein Telefon wünschen würde, wäre beispielsweise eine einfache Übersichtsseite, welche Anwendung auf welche Funktionen(GPS, Datenübertragung eingehend/ausgehend, welche IP-Adressen/Server, etc.) zugreift und eine Möglichkeit das (a) zu Beschränken und (b) zu Widerrufen. Das AccuWeather auf meinem Mobiltelefon fragt mich bei jedem Aufruf ob ich eine Netzverbindung erlauben will. Das ist zwar nett aber nervig. Ich würde das dieser Anwendung beispielsweise pauschal erlauben. Google Maps fragt mich nicht sondern greift einfach auf GPS und Datenverbindung zu. Ich wüsste nicht wie ich das verbieten kann. Andere Anwendungen haben mich bei der Installation einmal gefragt und fertig. Widerrufen ist nicht vorgesehen nur Deinstallation. Ich denke, da müssen die Mobiltelefonhersteller noch von den Desktopfirewallherstellern lernen.

Ach ja, weiß jemand zufällig ob es Truecrypt für das N97 mini gibt?

(Danke Sören)

F-Secure hat festgestellt, daß der Adobe Reader die gefährdetste Anwendung ist. Fast 49 Prozent aller Client-Side Angriffe richten sich gegen den Reader oder das Reader-Plugin im Browser. Auf Platz zwei mit rund 39 Prozent folgt Microsoft Word. Es wird also Zeit, über Alternativen nachzudenken. Mehr bei F-Secure.

(via The Register)

Und was für das iPhone gilt, gilt auch für das iPad. Gleiches OS!

Soso, Apple hat die ganzen Wifi-Scanner aus dem iTunes Store verbannt. Weil die Scanner um auf Wireless LAN Signale z.B. von offenen Hotspots in der Nähe zugreifen zu können, ein paar private APIs benötigt haben, die Apple nicht für die gemeinen Plebs-Entwickler freigegeben hat. Für das iPhone ist mir das im Grunde ja egal, für ein iPad keinen Wifi-Scanner mehr zu haben ist … typisch Apple halt.

Wann gibt’s eigentlich endlich das HP Slate mit Windows 7 und Back Track Linux?

Ich schwanke gerade ein wenig mit mir …

Ich bin ja viel unterwegs und regelmäßig in verschiedenen Hotels unterwegs während meine Freundin die Wohnung hütet. Die meisten Hotels haben inzwischen irgendwelche Systeme installiert, bei denen man am Empfang zeitlich beschränkt gültige Zugangsdaten für das Internet bekommt. Meist kommen dabei irgendwelche Ticketdrucker zum Einsatz.

Einige Hotels setzen jedoch weiterhin WEP/WPA/WPA2 mit einem festen Passwort ein. Dieses Passwort bekommt der Gast z.B. an der Rezeption oder steht im Zimmer in der Hotel-Infomappe.

Ist es jetzt unfair, auf einer Webseite wie dieser, die Zugangsdaten der WLAN-Zugänge solcher Hotels zu sammeln und zu veröffentlichen? Ich mache mir weniger Gedanken um die Kosten, da die meisten Hotels dafür eh eine Flatrate dafür haben. Problematisch könnte allerdings sein, wenn von außen illegale Zugriffe stattfinden und die Polizei mal schnell eine Hoteldurchsuchung durchführt. In Deutschland ist das mit der Unverletzlichkeit der Wohnung schließlich nicht mehr weit hin.

Also … soll ich nun oder nicht?

“Don’t just shorten your URL, make it suspicious and frightening.”

Beispielsweise diese:

http://5z8.info/dont-just-drizzle_k2c3j_malicious-cookie

Und wenn diese URL nicht funktioniert, dann vielleicht diese?

http://5z8.info/click-on-this-and-youll-be-taken-to-page-that-will-create-pop-up-windows-until-your-browser-crashes_l2y0d__init_download

oder doch besser was harmloseres?

http://5z8.info/amazon.com-phish_q4a6v_open_exe_begin_transfer

Passende URLs gibt’s bei http://www.shadyurl.com/. Klingt lustig, hat aber durchaus einen ernsten Hintergrund.

Eben gelesen:

“Isn’t that why we build DMZ networks with firewalls in front and behind them?  The point of doing that is so that it requires more than one server-side exploit to get into your organization.  Thanks to rich Internet client applications, it now only requires one client-side exploit to get into your organization.”

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 EinbrecherHinweise 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äßt. 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 muß.

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 Rechnleistung Kosten verpasst, ergibt sich eine einfach nutzbare Metrik, um Passwort-Cracking mit echten Kosten zu versehen. David Campbell hat das tabellarisch aufbereitet. Interessant ist, daß 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, daß ich da natürlich beliebige Daten hinausschleusen 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 andersrum:

Kann ein Angreifer im Internet einen bösartigen Webserver aufsetzen der automatisch diesen Network Connect startet und so einen VPN-Tunnel aufbauen, wenn der Benutzer ihn ansurft?

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, muß Mirosoft 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.

“A remote attacker can read, list and retrieve nearly all files on the System remotely.
Required is a valid samba account for a share which is writeable OR a writeable share which is configured to be a guest account share, in this case this is a preauth exploit.”

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.

“Nothing breaks if the admin sets “wide links = no” for that share: the link is not followed.”

Und dann driftet die Diskussion in das Verhalten von SMB auf Windows 2008 ab:

“Since Windows 2000 NTFS supports “junctions”, which pretty much resemble Unix symlinks, but only for directories. And at least since Vista, it also supports symlinks, which are designed to mimic Unix symlinks, and can point to files or directories. Junctions
and symlinks can cross volumes; symlinks can also refer to files or directories on network filesystems.”

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:

“All future versions of Samba will have the parameter “wide links” set to “no” by default, and the manual pages will be updated to explain this issue.”

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, daß es immer noch so viele Programme gibt, die sich nicht an diese Regel halten.