Android: Firefox übermittelt jede Tasteneingabe

Mein neuestes Projekt, die mobile Sicherheit von Handies ergründen, hat schon seinen ersten Treffer geliefert.

Zu meinem Erstaunen übertrug Firefox jede Tastatureingabe bei der Eingabe einer URL an einen dubiosen Server ohne Namen. Wie sich rausstellte, werden dadurch die Suchvorschläge erzeugt, auch wenn man URLs eintippt.

Das ist natürlich grade bei privaten Domains oder Urls mit Parametern ein Problem, weil irgendein Server das natürlich zusammensetzen kann. Ein eigenes Suchfeld, wie beim Desktopbrowser wäre die Lösung, aber da brauchen wir nicht drauf hoffen. Mir ist natürlich auch klar, daß der Platz auf einem Handy Display begrenzt ist, aber schön wärs, wenn der Datenschutz zuerst käme, man es also einschalten müßte.

Wer das nicht will, kann das in den Einstellungen zu Suchmaschinen abschalten.

Cinnamon Screensaver locked den Desktop nicht mehr

Es ist mal wieder soweit, der halbe Desktop (Linux) Planet ist in Gefahr, naja, fast 🙂

Das Problem

Der Cinnamon-Screensaver 3.4.1-1 lockt den Bildschirm nicht mehr, wenn er soll. Das öffnet natürlich fatale Sicherheitslücken in allen Bereichen, denn wenn der Bildschirmschoner angeht, lockt sich auch i.d.R. der Bildschirm, so daß ein Anderer den PC nicht übernehmen kann. Steht man nun von seinem Platz auf, gibt man mit der 3.4.1-1 die Kontrolle über seinen PC auf.

Und so beheben wir das Problem für Fedora

Zunächst öffnen wir eine ROOT Konsole, als User geht es leider nicht zu beheben. Dann entfernen wir als Root das Paket von PC :

rpm -e --nodeps cinnamon-screensaver

Von der Webseite „https://koji.fedoraproject.org/koji/packageinfo?packageID=16651“ laden wir uns die alte Version 3.4.0-1 passend zu unserem OS z.B. Fedora 25 x86_64  herunter . Danach installieren wir diese Version:

rpm -i ./cinnamon-screensaver-3.4.0-1.fc25.x86_64.rpm

Nun editieren wir noch die /etc/dnf/dnf.conf und tragen bei „exclude“ „exclude=cinnamon-screensaver*“ ein, andernfalls  wird der screensaver gleich wieder geupdated, wenn der nächste Cronjob dafür läuft.

Jetzt melden wir den aktuellen Benutzer vom Desktop ab und gleich wieder an. Das war es dann auch schon.

Bei Fedora ist ein entsprechender Bugreport am laufen, so daß mit einem Fix in den nächsten Tagen zu rechnen ist.

Update 26.6. 2017:

Leight Scott hat schnell reagiert und ein neues Paketupdate gepusht, welches das Problem behebt. Wer also cinnamon-screensaver in der dnf.conf gesperrt hat, kann die Sperre wieder aufheben.

 

 

 

Sparkassen-Shop mit Tracking und unsicheren Webseiten

Da wollte man so harmlos mal die Webseiten der Braunschweigischen Landessparkasse aka. Norddeutsche Landesbank oder kurz NORD/LB, benutzen, da zieht ein merkwürdiger Werbelink meine Aufmerksamkeit auf sich : http://www.sparkassen-shop.de

Hätte ich mal nicht hingeschaut :

SSL-Report des Sparkassen-shops mit Fehlermeldungen. Die Webseite ist als unsicher markiert und der Schlüssel entspricht nciht mehr so ganz den Ansprüchen an einen sicheren SSL Key

SSL-Report des Sparkassen-shops

Wie man schön sehen kann, stimmt was mit der HTTPS Seite nicht, weil der Browser schon von sich aus warnt, daß unsichere Links enthalten sind. Da sowas mein Job ist, kurz mal FireBug aktiviert und nachgesehen. Das hätte ich mal besser nicht machen sollen 😀

oh wie peinlich :  ERWISCHT beim Tracken

Da fand sich dann folgender Trackinglink der hauseigenen PIWIK Installation:

<img src=“http://piwik.sparkassenverlag.de/piwik/piwik.php?idsite=18″ style=“border:0;“ alt=““ />

sowas gehört auf einer HTTPS Seite natürlich auch mit HTTPS:// eingebunden !
Lustigerweise macht der Code-Schnippsel von PIWIK selbst, das richtig 🙂

Damit haben wir die Quelle der Browsermeldung, aber wenn wir schon dabei sind,  was zum Geier soll das sein ?!?

<a href=“http://www.blsk.de“ target=“_blank“>

Seit wann braucht man hardgecodete HTML Entitätsersatzanweisungen aus dem UTF-8 Zeichensatz für ein simples „://“ ?!?

Da kann man nur mit dem Kopfschütteln 🙂

Schlüssellängen

Aber warum habe ich jetzt eigentlich in dem SSL-Report die Schlüssellänge und den HASH-Algo markiert ?

Für die meisten (Männer) gilt die Formel :  Länge * Angelerfahrung => Menge(Selbstbewußtsein), lustigerweise gilt das auch für Webseitenverschlüsselungen. 2048bit Schlüssellänge waren vor Jahren mal empfohlen als ausreichend, ein paar konservative Fachmenschen würden das heute noch empfehlen, aber für eine Bank, da kann man nur zu einer vernünftigen Schlüssellänge von 4096+ Bits raten. Denn das sollte ja wohl sicher sein, oder war Fort Knox mit Wattebällchen abgesichert ?

Fazit

Diese Webseite gehört zu Kategorie: „Hätten Sie mal jemanden ohne Zertifikat gefragt“. Aber nicht alles ist schlecht, denn insgeheim hatte ich mit Google Analytics gerechnet zum Tracken der Benutzer und da ist mir PIWIK auf den eigenen Servern des Webseitenbetreibers natürlich lieber.

Da diese Grafik (oben) aber geladen wird, noch bevor man die Chance hatte, die Datenschutzerklärung zu lesen und die Seite ohne Tracking wieder zu verlassen, ist es wohl nur eine Frage der Zeit, bis der Datenschutz die Seite dicht macht. Wir sind ja hier in der EU, die auch eine Einwilligung zum Tracking per Einsatz von Cookies vorraussetzt.

Nur so ein Denkanstoß an die Verantwortlichen: Auf der Startseite brauch man noch kein Tracking, wie oft die aufgerufen wurde, sagt einem auch ohne weiteres das Apache Domlog.

Weiter als die Startseite durchzusehen, habe ich mich dann nicht getraut, ich hatte Angst, daß ich heute Nacht noch an dem Artikel sitzen würde 😉