Drei Anzeichen eines App-Angriffs, die Entwickler kennen sollten
Apps stehen unter Beschuss. Die Angriffe ereignen sich mit alarmierender Häufigkeit – einer Studie der University of Maryland zufolge alle 39 Sekunden – und die Erfolgswahrscheinlichkeit ist beunruhigend hoch.
Entwickler, die zunehmend die Last der Sicherung dieser Apps tragen, sind sich der Bedrohung durchaus bewusst. Eine Ende 2017 von NodeSource und Sqreen durchgeführte Umfrage unter Node.js-Entwicklern ergab, dass „mehr als ein Drittel aller Befragten (34 Prozent) der Ansicht sind, dass ihre Organisation in den nächsten sechs Monaten mit hoher Wahrscheinlichkeit Ziel eines groß angelegten Angriffs wird.“ Angesichts unserer eigenen Erkenntnisse , dass bei 86 % der Angriffe entweder die Anwendung selbst oder Identitäten der anfängliche Angriffsvektor sind, ist diese Annahme mehr als vernünftig.
Es mag beunruhigend sein, festzustellen, dass „35 % der Befragten nicht sicher waren, wie sie einen Angriff während seines Geschehens identifizieren können .“ Sie erwarten einen solchen Ansturm, sind sich aber nicht sicher, wie sie ihn erkennen können, wenn er eintritt. Wenn Sie nicht sicher sind, wie Sie einen laufenden Angriff identifizieren, ist es äußerst schwierig, ihn zu stoppen.
Umso beunruhigender ist es, dass 23 % der Node.js-Entwickler (23 Prozent) keinerlei Echtzeitschutz gegen Angriffe verwenden.
Die gute Nachricht ist, dass basierend auf unserer eigenen Forschung zum Stand der Anwendungsbereitstellung 2018, Die meisten Organisationen nutzen eine Art Echtzeitschutz gegen Angriffe. Vier von fünf verwenden zwei oder mehr Technologien, darunter eine Web Application Firewall (57 %), einen Runtime-Anwendungs-Selbstschutz (11 %) und eine Analyse des Benutzerverhaltens (26 %).
Allen diesen Technologien ist gemeinsam, dass es den Entwicklern oft an Transparenz mangelt. Sichtbarkeit ist erforderlich, da Sie zum Erkennen (und hoffentlich Identifizieren) eines Angriffs in der Lage sein müssen, abnormales Verhalten zu erkennen.
Anwendungen und ihre Dienste weisen ziemlich vorhersehbare Nutzungsmuster auf. Beispielsweise werden Single-Sign-On-Anwendungen (SSO) tendenziell am Montagmorgen stark und am Freitagnachmittag wenig genutzt. Kurz vor Finanzereignissen wie Zahltagen, dem Ende der Steuerperiode und dem Abschluss des Geschäftsjahres werden Finanz-Anwendungen häufig genutzt.
Sogar verbraucherorientierte Anwendungen weisen vorhersehbare Nutzungsmuster auf, die zur Erkennung ungewöhnlichen (und potenziell gefährlichen) Verhaltens herangezogen werden können. So veröffentlichte Malauzai Software im April 2017 einen seiner monatlichen „Little Data“-Berichte, der auf Nutzungsdaten von über „435 Banken und Kreditgenossenschaften basiert und 13,2 Millionen Anmeldungen von 730.000 aktiven Internet- und Mobile-Banking-Nutzern abdeckt.“ Darin erfahren wir, dass „100 % der Endbenutzer ihre Kontostände einsehen und den jüngsten Transaktionsverlauf überprüfen können. Der Grund hierfür ist, dass Salden und der aktuelle Verlauf auf der Zielseite für alle sichtbar angezeigt werden. Und deshalb kommen sie. 77 % der Zeit. In 77 % der Fälle überprüft ein Benutzer lediglich Kontostand und Verlauf. Nur 23 % aller Interaktionen im digitalen Banking gehen über die Abfrage von Kontoständen und Verlauf hinaus und führen andere Aufgaben aus.“
Man könnte daher davon ausgehen, dass ein plötzliches Interesse an anderen Transaktionsarten ein Hinweis auf einen Angriff sein könnte.
Leider stehen solche Statistiken nicht immer und für jede Anwendung sofort zur Verfügung. Aus diesem Grund ist die Sichtbarkeit (Überwachung) wichtig, damit Sie eine Basislinie festlegen können, anhand derer Anomalien offensichtlich werden. Natürlich deuten nicht alle Anomalien auf einen Angriff hin. Ein Anstieg der SSO-Dienstnutzung Mitte der Woche kann auf eine Frist zur Änderung von Unternehmenskennwörtern oder darauf zurückzuführen sein, dass Montag und Dienstag Feiertage waren und niemand im Büro war. Wenn Sie jedoch über eine Baseline verfügen, können Sie das Verhalten, das auf einen laufenden Angriff schließen lässt, leichter erkennen.
Achten Sie unbedingt auf diese drei abnormalen Nutzungsmuster, um sicherzugehen, dass es sich nicht tatsächlich um einen Angriff handelt. Denn das ist ziemlich oft der Fall.
1. Dramatischer Anstieg der Verbindungen. Vielleicht sind Sie gerade viral gegangen, aber wahrscheinlich steckt noch etwas anderes dahinter. Wenn Sie einen deutlichen Anstieg der Verbindungsraten feststellen, sollten Sie sofort prüfen, ob es zu einer entsprechenden Zunahme des Netzwerkverkehrs kommt. Wenn nicht, sollten Ihre Spinnensinne kribbeln, da es sich um einen möglichen Angriff handelt. Von allen HTTP-basierten DDoS-Angriffen sind GET-Floods am einfachsten durchzuführen, da sie lediglich darauf beruhen, einer Anwendung eine Unmenge an HTTP-GETs zuzuführen und sonst nichts. Sie versuchen oft nicht einmal, auf echte URLs zuzugreifen, da es lediglich darum geht, so viele Verbindungen wie möglich zu verbrauchen und Sie in eine Überlastungssituation zu zwingen.
Wenn der Anstieg speziell auf URLs oder Dienste abzielt, die Anmeldungen ermöglichen, könnten Sie Opfer eines Brute-Force-Angriffs werden, um Zugriff zu erhalten.
Achten Sie auf Serverfehler, zunehmend nachlassende Leistung und Ressourcenerschöpfung als Anzeichen eines anhaltenden Angriffs.
2. Größe der ausgehenden Antwort. Eine plötzlich große ausgehende Antwort kann auf einen erfolgreichen Exfiltrationsangriff hinweisen, bei dem der Angreifer Zugriff auf Daten erlangt hat, auf die er keinen Zugriff haben sollte. Dies ist eines der wichtigsten Warnzeichen für einen erfolgreichen SQLi-Angriff, da Angreifer häufig Platzhalter verwenden, um unbefugten Zugriff auf Daten zu erhalten. Man sollte meinen, dass SQLi ein so gut verstandener Angriffsvektor ist, dass wir das inzwischen abgedeckt hätten. Allerdings wird SQLi in zahlreichen Branchenberichten jedes Jahr konstant zu den erfolgreichsten Angriffen gezählt.
Der Angriff zielt grundsätzlich darauf ab, Beschränkungen beim Datenzugriff zu umgehen. Anstatt also einen einzigen Datensatz (oder sogar nur einige wenige) zu erhalten, kann der Angriff Tausende empfangen. Ein erfolgreicher Angriff macht sich dann dadurch bemerkbar, dass die zurückgegebene Datenmenge erheblich größer als normal ist.
Jeder signifikante Unterschied in der Antwortgröße sollte Grund genug für eine sofortige Untersuchung sein.
3. Stürzt ab und schlägt fehl. Diese können zwar durch Defekte oder versehentlich „falsche“ Eingaben erklärt werden, sie können jedoch auch auf Versuche hinweisen, Puffer in Drittanbieterbibliotheken oder Webserverplattformen (oder Ihrer Anwendung) zu überlaufen, in der Hoffnung, eine neue (oder alte) Sicherheitslücke auszunutzen. Zwar ist es schön, dass sich Systeme heute einfach selbst „neu starten“ können, aber es ist nicht schön, den Grund für den Neustart zu ignorieren .
Auch wenn die Versuchung groß ist, gelegentliche Abstürze zu ignorieren, tun Sie es nicht.
Ignorieren Sie Abstürze und Störungen nicht und ziehen Sie Architekturen in Betracht, die es Ihnen ermöglichen, fehlerhafte Systeme unter Quarantäne zu stellen, bis Sie sie überprüfen können.
Natürlich handelt es sich hierbei nicht um eine vollständige Liste, aber sie ist ein guter Ausgangspunkt, um zu erkennen, wann eine Anwendung möglicherweise angegriffen wird – und um den Angriff sofort zu stoppen.
Bleib sicher!