Google nutzt Fernwartung auf Android Smartphones

Google hat erstmals Gebrauch von der Möglichkeit gemacht, aus der Ferner auf Android-Smartphones installierte Applikationen zu zugreifen und diese auch zu ändern.

Wie auch bei Apple wird der Android Market von Google überwacht. Dabei kommt es hin und wieder vor, dass Anwendungen gelöscht werden, da diese gegen Richtlinen verstoßen. Diesen Schritt ging Google nun das erste Mal und löschte 2 Apps aus seinem Store. Allerdings dem nicht genug: Google löschte die Anwendungen auch gleich auf den Smartphones auf denen die Apps installiert waren.

Die beiden betreffenden Anwendungen waren von Sicherheitsforschern zu Testzwecken veröffentlicht worden um zu demonstrieren wie einfach sich Schadsoftware über solche Stores verbreiten ließe. Beim Download wurde der Nutzer mit falschen Versprechen zu einem Download weitergeleitet, bei dem dann Schadsoftware lauern könnte. Die Anwendungen selbst richteten keinen Schaden an und wurden von den meisten Benutzern ohnehin wieder entfernt.

Google entschied sich allerdings die Anwendungen über die Fernwartungsfunktion von den Geräten zu entfernen. Diese Möglichkeit ist eine Sicherheitsmaßnahme und dient dazu Anwendungen im Notfall zu entfernen.

Für mich als Nutzer beschleicht sich nun aber das etwas mulmige Gefühl, was Google mit dieser Fernwartungssoftware noch so alles machen kann. Da das Smartphone hauptsächlich zuhause an der WLAN Leitung hängt, würde man es gar nicht erst bemerken, wenn klammheimlich Daten übermittelt werden, die über eine Fernwartung hinausgehen.

Gerade wegen des kürzlichen WLAN Datenskandals bei Google sollte man sich hier doch die ein oder andere Überlegung machen wie man das Gerät in Zukunft besser schützen kann.

Mozilla Weave Server

Nachdem ich die Nase gestrichen von Google Chrome und dem Addon Proxy Switchy habe, bin ich wieder zum guten alten Firefox heimgekehrt. Da ich mittlerweile auf 3 Geräte meine Bookmarks etc. syncen muss, war ich nun bei Firefox auf der Suche nach einem passenden Synctool.

Es bot sich daher an, Mozilla Weave genauer unter die Lupe zu nehmen. Auf der Wikiseite wird empfohlen den Mimimal zu installieren, da die Vollversion wohl zu kompliziert wäre.

Ja genau, ich installier auch ne Minimal Version. Nix da, Vollversion gezogen und rein ins Getummel. Nach rnd. 4 Stunden, bin ich nun um die Erkenntnis reicher, dass die Version einen Bug im Authentifizierungsmodul hat, man sich deswegen am Server nicht anmelden kann. Super So sind die Daten sicher, man kann sich gar nicht erst anmelden um welche hochzuladen.

Der Minimal Server, den ich mir danach angesehen habe, arbeitet mit einer schlichten SQLite Datenbank, in der per md5 Hash die Daten eingespeist werden. Die SHA256 Funktion, sowie die salted Passwörter fehlen gänzlich. Schade, denn ich verstehe nicht, warum man diese Funktionen rausgeräumt hat, da die Minimalversion auch nur abgespeckt ist.

Alles in Allem ist der Weave Server in der Vollversion noch verbuggt und muss noch einmal auf die Werkbank um überarbeitet zu werden. Die Minimalversion empfehle ich ebenfalls nicht, da die md5 Hashfunktion aus meiner Sicht lange ausgedient hat und ich nicht nachvollziehen kann, warum man beim Abspecken der Voll- auf die Minimalversion dieses Feature gleich mit entfernt hat.

Doch Mozilla bietet auch eigene Server an auf die man die Daten hochladen kann. Ich habe mir dazu die Spezifikation angesehen und bin der Meinung dass es sicher genug ist, die Daten dort zu parken. Man muss allerdings bedenken, dass sicherlich Statistiken aus den Daten gezogen werden, auch wenn diese nach dem Schema von GPG verschlüsselt sind. Ob man diese Daten preisgeben möchte ist jedem selbst überlassen.

PLESK 9.5.1 Debian Lenny Key Update schlägt fehl

Unter Debian Lenny hat sich laut Parallels ein Bug in Curl eingeschlichen, so dass das Keyupdate über die PLESK Oberfläche fehlschlägt. Man könnte nun a) curl kompilieren, b) Curl aus Debian Etch installieren oder c) PLESK deinistallieren, die Lizenzkosten in einen ausführlichen Linux Debian Kurs oder in adäquate Bücher investieren und… ach ne c) scheidet ja aus… Nun gut.

Hier also die Lösung dazu

1) Anlegen der Datei “psacurl”

Als erstes legen wir die Datei “psacurl” unter /opt/psa/bin oder dem entsprechenden BIN Verzeichnis von PLESK an und füllen diese mit folgendem Inhalt:

#!/bin/bash
/usr/bin/curl -k --sslv3 $@

Dieser Datei verpassen wir die Rechte 0755, chmod sollte als Programm hier die erwarteten Dienste verrichten.

2) .profile Datei für psaadm

Damit wir nun das von uns erzeigte “psacurl” auch PLESK beibringen bediene ich mich hier einfach einer .profile Datei die einen Alias für den eigentlichen curl Befehl enthält. Inhalt der Datei:

alias curl='/opt/psa/bin/psacurl'

Um die .profile Datei nun auch nutzen zu können ist eine kurze Änderung in der /etc/passwd erforderlich um dem User “psaadm” eine Shell zu verpassen, nach dem Wechsel auf die Userebene führen wir ein simples Befehlchen aus:

. .profile

Bitte beachten: Der Punkt am Anfang muss ebenfalls eingegeben werden, sowie die nachfolgende Leerstelle. Damit wird das Profil neu geladen und absofort ist der Alias aktiv.

Fertig

PLESK Postfix, Amavis und Clamav

Bekanntermaßen reicht der Softwarehersteller Parallels für die Linux Variante von PLESK ausschließlich den tollen Dr. Web oder Kaspersky als Anti-Virenmodul. Beide sind kostenpflichtig und nehmen nicht wenig an Gebühren. Bei Dr. Web sind es schon mal 300€, Kaspersky rechnet pro Postfach.

Aber: Es gibt Abhilfe. Dank Amavis, Postfix und Clamav kann man sich so ganz einfach einen kostenfreien Anti-Virenscanner schaffen.

Wie immer vorne weg: Wer keine Ahnung von Linux hat, nicht weiss was eine Shell ist und bei der Frage nach dem Texteditor unter Linux Notepad empfiehlt, sollte sich gleich von jemanden der sich mit dem Ganzen auskennt helfen lassen. Hier gibt es dazu Hilfe.

Voraussetzungen:
PLESK unter Linux, Clamav Daemon und Freshclam, Amavis installiert.

1) Konfiguration Amavis

Die Grundkonfiguration von Amavis sollte bereits erledigt sein, soll heißen ich erkläre hier nicht weiter wie man Clamav und Amavis verbindet, es gibt unzählige Anleitungen. Neu ist allerdings, dass wir Amavis nicht wie üblich auf Port 10024 laufen lassen, sondern wir müssen ihm einen neuen Port zuweisen, da in den Regionen 10020 – 10030 PLESK mit den ganzen Mailhandlern arbeitet. Ich vergebe daher die Ports 6000 und 6001. Unter Debian nutzen wir dabei 2 Dateien:

50-user.conf

$forward_method = ‘smtp:[127.0.0.1]:6001′;
$notify_method = ‘smtp:[127.0.0.1]:6001′;

In der Hauptkonfigurationsdatei stellen wir ebenfalls den Port um:

20-debian-defaults.conf

$inet_socket_port = 6000;

Damit sind die ersten Schritte schon erledigt. Der forward und notify Port muss übrigens angegeben werden. Wird er das nicht gibt es folgenden Fehler:

(!) WARN: sending SMTP QUIT command failed: 000

2) Postfix main.cf

Die beiden folgenden Einstellungen in der main.cf und master.cf von Postfix müssen im Übrigen vor Veränderungen geschützt werden. PLESK hat die Angewohnheit die Dateien bei jeder Änderung um Maileinstellungsbereich sowie auch bei Updates von PLESK komplett zu überschreiben. Jegliche Versuche PLESK zu erklären, dass nicht zu machen sind gescheitert. Ein chattr hilft hier auf jeden Fall weiter, sofern man EXT3/4 hat und nicht reiserfs.

Fangen wir also mit der main.cf an. Dort muss nur ein kleiner Eintrag eingefügt werden, da das meiste in der master.cf passiert.

main.cf

content_filter = smtp-amavis:[127.0.0.1]:6000

Nachdem dieser Eintrag an das Ende der Datei gesetzt wurde, sind wir hier auch schon fertig. Als nächstes folgt nun die master.cf:

master.cf

plesk_virtual unix – n n – - pipe flags=DORhu user=popuser:popuser argv=/usr/lib/plesk-9.0/postfix-local -f ${sender} -d ${recipient} -p /var/qmail/mailnames
127.0.0.1:10025 inet n n n – - spawn user=mhandlers-user argv=/usr/lib/plesk-9.0/postfix-queue 127.0.0.1 10027 before-queue
127.0.0.1:10026 inet n – - – - smtpd -o smtpd_client_restrictions=  -o smtpd_helo_restrictions=  -o smtpd_sender_restrictions=  -o smtpd_recipient_restrictions=permit_mynetworks,reject  -o smtpd_data_restrictions=  -o receive_override_options=no_unknown_recipient_checks
127.0.0.1:10027 inet n n n – - spawn user=mhandlers-user argv=/usr/lib/plesk-9.0/postfix-queue 127.0.0.1 10026 before-remote
plesk_saslauthd unix y y y – 1 plesk_saslauthd status=5 listen=6 dbpath=/plesk/passwd.db

submission inet n – - – - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_proxy_filter=127.0.0.1:10025

smtps inet n – - – - smtpd -o smtpd_proxy_filter=127.0.0.1:10025 -o smtpd_tls_wrappermode=yes

smtp-amavis unix -      -       n       -       2       smtp -o smtp_data_done_timeout=1200 -o disable_dns_lookups=yes -o smtp_send_xforward_command=yes
127.0.0.1:6001 inet n  -       n       -       -       smtpd -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks=127.0.0.0/8 -o strict_rfc821_envelopes=yes

Das sind die kompletten Einträge die gesetzt werden müssen. Es werden vermutlich einige schon vorhanden sein. Ich empfehle einfach alles ab “plesk_virtual” rauszuwerfen und gleich neu einzusetzen, das erspart die Sucharbeit. Nachdem wir auch diesen Eintrag erledigt haben, sichern wir die beiden Dateien gegen Veränderung, starten Postfix neu und fertig

Vorher sollte aber jeder in PLESK selbst den Virenfilter auf “keinen” umgestellt haben, damit nicht doch noch Dr. Web im Hintergrund weiterläuft.

Fix für Internet Explorer 6 + 7

Microsoft hat ein sogenanntes FixIt für das offene Sicherheitsloch im Internet Explorer 6 und 7 veröffentlicht. Leider gibt es diesen Fix nur für Windows XP und Windows Server 2003. Wer versucht diesen auf anderen Windows Systemen zu installieren, wird feststellen dass er dort wirkungslos ist.

Internet Explorer 8 soll nach Aussage von Microsoft gar nicht betroffen sein.

Um sich auch ohne den Fix zu schützen empfiehlt Microsoft weiter, dass man den Browser einfach im geschützten Modus betreiben soll, einen kompletten Schutz ermöglicht aber auch diese Einstellung nicht.

Angreifer können über diese Sicherheitslücke beliebigen Programmcode auf fremden Systemen ausführen, was auch schon rege genutzt wird. Microsoft konnte sich ferner noch nicht entscheiden, ob ein Patch für die betroffenen Versionen außerhalb der Reihe erscheint. Ansonsten müssten die Nutzer bis zum 13.April 2010 warten, denn dann ist wieder Patchday.

Opera 10.51 RC

Entweder hat Opera einen ganzen Batzen Entwickler eigestellt um noch schneller entwickeln zu können oder man bezahlt Überstunden doppelt, denn die derzeitige Entwicklungswut kann ich mir anders nicht mehr erklären.

Vor kurzem ist die 10.50 von Opera erschienen und schon gibt es eine weitere Version in der die neue Java-Engine Caracas verbessert und stabiler wurde. Ich habe mir die neue Version direkt geladen und bin diese am testen.

Mit einem Satz: Einfach ein Gedicht. Während man bei Firefox mittlerweile das Gefühl hat auf einem Bobbycar durchs Internet zu rutschen, so legt man bei Opera den Turbo ein.

Ich kann nur jedem empfehlen sich den Browser genauer anzusehen und sich genau zu fragen, ob er die ganzen Addons die er in Firefox installiert hat überhaupt braucht.

Windows XP Security Patch legt System lahm

Ein dieser Woche veröffentlichter Sicherheitspatch scheint fehlerhaft zu sein. Das Ergebnis ist ein Bluescreen und Windows XP bootet nicht mehr.

Microsoft hat den Fehler zwischenzeitlich bestätigt und erklärt dass der Patch des Security Bulletins MS10-015 fehlerhaft ist. Die Systeme lassen sich nicht mehr booten und es kommt zu einem Systemabsturz. Als Reaktion von Microsoft wurde der Patch von den Updateservern entfernt.

Eine Behebung des Fehlers ist allerdings leider noch nicht in Sicht. Es wurde aber seitens der Redmonder versichert, dass der Fehler behoben und der Patch neu aufgelegt wird. Bis dahin müssen die User selbst das Problem in den Griff bekommen. Eine kurze Anleitung habe ich aus dem Microsoft Forum übersetzt:

1. Als erstes muss man die original Windows XP CD oder DVD in das entsprechende Laufwerk einlegen und von dieser in die recovery console booten. Sobald man in der recovery console ist gibt es die Möglichkeit das System wieder zu reparieren

2. Folgenden Befehl eingeben: CHDIR $NtUninstallKB978262 $spuninst

3. Danach folgenden Befehl verwenden: BATCH spuninst.txt

4. Und zum Schluss: systemroot

5. Die Schritte 2 – 4 für die nachfolgenden Patches verwenden:

KB978262
KB971468
KB978037
KB975713
KB978251
KB978706
KB977165
KB975560
KB977914

6. Sobald alle Patches entfernt sind, den Befehl “exit” eingeben und rebooten. Damit sollte das System wieder laufen.