Archiv der Kategorie: Risiken

© peshkova - Fotolia.com

HTTPs: Unverzichtbar in der heutigen Zeit

Sobald Passwörter zum Login für Webseiten verwendet werden, ist HTTPs unverzichtbar. Im Folgenden möchte ich aufzeigen, warum dem so ist! Ich beginne mit einer Übersicht der gängigsten Authentifizierungen für Web-Portale.

(1) Klartext Login

Die einfachste Variante: Der Login im Klartext.

Account anlegen

Der Benutzername und das Passwort werden im Klartext an den Server gesendet.

Plaintext Registration

Plaintext Registration

Anmeldung

Zur Anmeldung wird der Benutzername und das Passwort im Klartext an den Server gesendet.

Plaintext Login

Plaintext Login

Sicherheit

Die folgende Analyse wertet die Sicherheit des Verfahrens aus. Die Liste ist ein Auszug einiger wichtiger Sicherheitsparameter, jedoch nicht abschließend.

Klartextpasswort geschütztNein
Replay-Angriff verhindertNein. Wird das Passwort während der Anmeldung mitgeschnitten, kann dieses zum Login genutzt werden.
Login nach Kompromittierung der Datenbank verhindertNein. Das in der Datenbank gespeicherte Passwort kann zum Login verwendet werden.
Man-in-the-Middle verhindertNein. Es gibt keine Möglichkeit sicherzustellen, dass der Client direkt mit dem Server kommuniziert.

Fazit: Erhebliche Risiken; bietet über unverschlüsselte Kommunikationskanäle keinerlei Sicherheit.

Weiterlesen

© timkaekler - Fotolia.com

PHP Anwendungen absichern

Nachdem ich vor knapp 3 Wochen zufällig festgestellt habe, dass über das PHP-Webinterface von einem der größten deutschen Web-Hoster nahezu alle Rechnungen, unter anderem inkl. Kunden-Adressen, gekürzten Bankverbindungen, Domains sowie IP-Adressen öffentlich abrufbar sind, habe ich mich entschieden, einen kurzen Beitrag über die Absicherung von Web-Anwendungen zu schreiben. Zur Ausnutzung der Lücke war keinerlei technisches Fachwissen erforderlich - das Skript zum Download der Rechnung hat einfach jede beliebige Rechnung ungeprüft ausgeben. In der URL musste nur die gewünschte Rechnungsnummer eingegeben werden. Aufgefallen ist es mir, nachdem ich bemerkt hatte, dass ich eine Rechnung von meinem Zweitaccount beim Anbieter herunterladen konnte, ohne dass ich dort noch angemeldet war.

Problem 1: Keine Authentifizierung

Oftmals finde ich Anwendungen, die zwar einen Login haben, dieser jedoch nur den Zweck hat, auf einen geschützten Bereich weiterzuleiten. Beim Öffnen einer Seite in einem geschützten Bereich wird nicht erneut geprüft, ob der User authentifiziert ist. Dabei lässt sich dies unglaublich leicht realisieren:

<?php
session_start();
 
if (isset($_SESSION['username'])) {
   --> Passt
} else {
   --> Zur Anmeldung weiterleiten
}
?>

Geschützter Content sollte niemals (!) ohne Authentifizierung ausgeführt werden.

Problem 2: Keine Autorisierung

Neben der Authentifizierung sollte stets geprüft werden, ob der User auch autorisiert ist, die gewünschte Aktion auszuführen. Im Beispiel einer Rechnungsabfrage über SQL darf niemals die Anfrage ungeprüft über SQL ausgeführt werden. Die SQL Anfrage sollte soweit eingeschränkt sein, dass ein User nur auf Daten zugreifen kann, die für ihn bestimmt sind.

Problem 3: Unverschlüsselte Übertragung

Ein geschützter Bereich bringt wenig, wenn die Anmeldung im Klartext durchgeführt wird. Es kann nur in den seltensten Fällen sichergestellt werden, dass die Daten unterwegs nicht ausgelesen werden können. Einen HTTP Request mit Wireshark auszulesen, bedarf keines großen Könnens. Die Thematik wird umso schwerwiegender, wenn im Unternehmen Single-Sign-On (SSO) bzw. LDAP verwendet wird.

Weiterlesen

© violetkaipa - Fotolia.com

Häufige Schwachstellen in der Verschlüsselung durch Apps

Nachdem kurz nach der WhatsApp Übernahme die Suche nach und Diskussion über einen sicheren Messenger begann, möchte ich im Folgenden kurz auf die häufigsten Fehler aufmerksam machen, die App-Entwickler bei der Implementierung von Verschlüsselung zur Datenübertragung machen.

Schwachstelle 1: Die App nutzt einen gleichbleibenden, symmetrischen Schlüssel

Leider immer noch sehr häufig in Verwendung - gleichbleibendene, symmetrische Schlüssel.

symmetrische Verschlüsselung

Das Risiko liegt klar auf der Hand. Der Schlüssel muss im Client zu irgendeiner Zeit im Klartext vorliegen und kann ausgelesen werden. Ab diesem Punkt ist jede Verschlüsselung hinfällig - die Kommunikation jedes Clients kann entschlüsselt werden.

Weiterlesen

© apops - Fotolia.com

Social Engineering Angriffe

Social Engineering oder in diesem Kontext auch Social Hacking ist eine der größten Gefahren für die IT-Sicherheit von Unternehmen. Ich möchte mit diesem Beitrag eine Beitragsreihe in meinem IT Security Blog beginnen, die Sicherheitslücken in Unternehmens- und Privatnetzwerken aufzeigen soll, denen ich immer wieder begegne. Die meisten Unternehmen legen den Fokus zum Schutz ihrer IT Infrastruktur viel zu eng und verstehen darunter meist nur die Sicherheit ihrer Server und den Grundschutz der Clients. Thematiken wie Social Engineering werden meist vollkommen außer Acht gelassen.

Am Beispiel des Unternehmens "Weltweit Dienstleistungs GmbH" möchte ich die Knackpunkte der IT Sicherheit näher erläutern. Das Netzwerk des Unternehmens sieht wie folgt aus:

Darstellung eines Unternehmensnetzwerkes mit DMZ, internem Netz und BYOD Schnittstelle über W-Lan.

Die Graphik beinhaltet ein Netzwerk mit einem Web- und E-Mail-Server in einer DMZ. Im internen Netzwerk sind Mitarbeiter PCs, ein Netzwerkdrucker und ein interner Dateiserver. BYOD Geräte sind über W-Lan mit dem Netzwerk verbunden.

Das obere Netzwerk ist mit dem Internet verbunden und durch eine Firewall geschützt. Die Web- und E-Mailserver befinden sich in einer DMZ (demilitarisierten Zone). Das interne Netzwerk ist durch eine Firewall von der DMZ getrennt. Es existiert ein W-Lan um BYODs (="Bring your Own Device"), also von Mitarbeitern selbst mitgebrachte IT-Geräte, an das interne Netzwerk anzuschließen. Die PCs sind auf einem aktuellen Stand und mit einer marktüblichen Antivirenlösung ausgestattet.

Eine erste, kurze Analyse der Dinge, die gut am oberen Aufbau sind:

  • Es wird eine dedizierte Firewall verwendet, um das gesamte Unternehmensnetzwerk zu schützen.
  • Der Web- und E-Mail-Server liegen in einer 2-stufigen-DMZ. Der Webserver ist der häufigste initiale Angriffs- und Schwachpunkt in einem Unternehmensnetzwerk.
  • Web- und E-Mail-Server liegen auf verschiedenen Servern. Damit kann der Zugriff auf E-Mails vermieden werden, wenn der Webserver kompromittiert worden ist.
  • Das interne Netzwerk ist durch eine Firewall geschützt. Durch diese Maßnahme kann bei einer Kompromittierung innerhalb des DMZ ein Angriff auf das interne Netzwerk erschwert werden.

Weiterlesen