Wenn die URL-Domäne nicht ausreicht, um einen Phish zu vermeiden

Eines der häufigsten Mantras in Sicherheitsschulungen lautet: „Prüfen Sie die URL, um festzustellen, ob sie auf den rechtmäßigen Anbieter verweist oder nicht!“

Das ist ein guter Ratschlag. Bringen Sie sich selbst und anderen bei, wie man URL-Links (Internet Uniform Resource Locator) liest, damit sie Tricks von Phishern erkennen können, die versuchen, sie auf gefälschte Websites zu locken. Wenn Sie wissen, wie man den Unterschied zwischen microsoft.com und microsoft.com.biztalk.ru erkennt, können Sie sich eine Menge Ärger und vergeudete Stunden ersparen.

Sogar ich sage das immer wieder (d. h. „Prüfen Sie die URL“). Ich habe sogar einen einstündigen Webinar-Kurs mit dem Titel „Combating Rogue URL Tricks“. Ich habe einen entsprechenden Blog-Artikel verfasst, und Sie können hier sogar eine nützliche PDF-Datei mit den „12 häufigsten betrügerischen URL-Tricks“ herunterladen. Ich bin sehr dafür, dass jeder lernt, wie man betrügerische URLs erkennt.

In den meisten Fällen reicht es aus, nach dem vollständig qualifizierten Domänennamen (z. B. microsoft.com) zu suchen und ihn zu identifizieren, um zu erkennen, was legitim ist und was nicht. Hier ist ein Screenshot aus meiner Präsentation zu Rogue URLs, in der ich erkläre, wie man den referenzierten DNS-Domänennamen erkennt.

Übersetzt mit www.DeepL.com/Translator (kostenlose Version)

Bei der überwiegenden Mehrheit der Phishing-Angriffe wird ein gefälschter (z. B. ähnlich aussehender oder ähnlich klingender) Domänenname in der URL verwendet. Mit einem kurzen Blick lässt sich also feststellen, ob eine URL auf eine legitime Website verweist oder nicht.

Aber nicht immer. Wie ich in meinem Webinar über betrügerische URLs (sowie in einem Artikel und einer PDF-Datei) darlege, gibt es eine Vielzahl von Tricks, mit denen Phisher Menschen dazu bringen können, auf eine betrügerische URL zu klicken. Eine der raffiniertesten Methoden ist der so genannte Umleitungsangriff.

Umleitungsangriffe

Bei Umleitungsversuchen verwendet der Phisher einen legitimen Domänennamen und eine legitime Website, hat aber eine Schwachstelle in der Art und Weise gefunden, wie der Host die eingegebenen zusätzlichen Variablen interpretiert. Lassen Sie mich das genauer erklären. Wenn Sie eine URL (z. B. example.com) eingeben oder anklicken, verwendet diese URL DNS (Domain Name Service), um den eingegebenen oder angeklickten Namen umzuwandeln und Sie zu der IP-Adresse und dem Dienst zu leiten, der den Inhalt für diese URL hostet. Wenn Sie www.microsoft.com eingeben, gelangen Sie zu dem Server/Dienst, auf den der Host antwortet und der die Inhalte für die angegebene URL bereitstellt. Wenn die angegebene URL jedoch ein Fragezeichen (?) nach dem Domänennamen enthält, wird alles nach dem Fragezeichen als „Variable“ betrachtet und zur Überprüfung und Bearbeitung an den antwortenden Server/Dienst zurückgegeben. Hier ist eine weitere Folie aus meiner Rogue URL-Präsentation, die sich mit URL-Variablen beschäftigt.

Übersetzt mit www.DeepL.com/Translator (kostenlose Version)

Hinweis: Ich werde Server/Dienste vereinfachen, indem ich einfach den umfassenderen Dienst sage.

Entscheidend ist, dass alles nach dem ersten Fragezeichen in einer URL als Variable behandelt wird und mehrere Variablen durch ein kaufmännisches Und (&) getrennt werden können. Normalerweise werden Variablen vom Hosting-Dienst verwendet, um Benutzer und ihre Aktivitäten zu verfolgen, aber die Variablennamen und ihre Verwendungszwecke können vom Hosting-Dienst beliebig gewählt werden.

Hinweis: Ich vereinfache dieses Thema stark, um zu verhindern, dass dies ein 50-seitiges Ebook wird.

Ein Teil des Problems besteht darin, dass die Variablen und ihre Werte von jedem geändert werden können und dem Host-Dienst zur Auswertung vorgelegt werden. Nun, normalerweise ist das kein Problem. Normalerweise sucht jeder Hosting-Dienst nur nach bestimmten Variablennamen und -werten und ignoriert einfach alles, was er nicht versteht. Und man sollte meinen, dass alles, was er akzeptiert und „versteht“, weder für den Dienst noch für seine Nutzer gefährlich ist.

Es hat sich herausgestellt, dass viele Dienste (seit Jahrzehnten) die Übermittlung missgestalteter Variablen zugelassen haben, die unbeabsichtigte, nicht autorisierte Aktionen auslösen können. Was diese nicht autorisierten Aktionen sind, hängt vom Host ab und davon, was der Host aufgrund der fehlerhaften Variablenwerte zulässt und tut. Das einfachste Beispiel für Variablenmissbrauch ist eine Variable, die von einer Website verwendet wird, um Benutzer zwischen Klicks zu verfolgen. Nehmen wir an, eine Variable mit dem Namen „user“ verfolgt Benutzer anhand der Nummer ihres Identitätskontos, einschließlich der Kreditkartendaten. Ein Beispiel: ?user=456789 ist eine Nummer, die zu meiner Identität führt. Ein Hacker könnte versuchen, ?user=456788 zu verwenden und sehen, was passiert. Vielleicht werden dadurch die Sitzung und die Kreditkartendaten eines anderen Benutzers angezeigt. Aus diesem Grund sollten Websites, die Benutzer mithilfe von URL-Variablen verfolgen, sicherstellen, dass die Benutzer-ID, die verwendet werden könnte, so zufällig wie möglich ist und nicht erraten werden kann – damit ein Angreifer nicht einfach herausfinden kann, was ein gültiger Wert für die Benutzervariable ist und was nicht, und das Konto des Benutzers aufrufen kann.

Einige Websites erlauben die Erstellung von URLs, die es Dritten ermöglichen, Benutzer auf eine andere Website umzuleiten. Vielleicht möchte die Website beispielsweise zulassen, dass jeder, der an ihrem Standort ankommt, nach dem Besuch ihrer Website auf der Website des Drittanbieters landet. Die „verweisende“ URL könnte eine Variable enthalten, die angibt, wie die Ursprungs-URL lautet. Der Host-Dienst sieht sie, bearbeitet den Benutzer und schickt ihn anschließend zurück zur Ursprungswebsite. Erfinden wir ein einfaches Beispiel für dieses Szenario mit einer URL, die etwa so aussieht: www.example.com?referringURL=www.originalwebsite.com. Die Beispiel-Website möchte den Benutzer einfach von der Website, von der er gekommen ist, zurückschicken. Die Absicht ist ziemlich harmlos. Die Tatsache, dass jede URL eine Person zu einer bestimmten Website leiten kann und dann den Benutzer (eigentlich seinen Browser) auf eine beliebige Website der Wahl des URL-Erstellers umleitet, ist als „offene Umleitung“ bekannt.

Ein bösartiger Hacker könnte eine Phishing-E-Mail verwenden, die scheinbar von einer seriösen Website stammt, z. B. example.com, aber eine bösartige Umleitungs-URL enthält, die den Benutzer nicht auf seine ursprüngliche Website zurückbringt, sondern auf eine neue, bösartige Website (z. B. www.example.com?referringURL=www.maliciouswebsite.com). Die Hosting-Website hatte nie die Absicht, das Opfer an einem anderen Ort als der ursprünglichen Website „abzusetzen“, aber da sie die Variable nicht sicher genug „analysiert“ hat, setzt sie es einfach dort ab, wo die übermittelte (vom Angreifer erstellte) URL angibt, den Benutzer abzusetzen. Dies ist ein böswilliger Umleitungsangriff. Sie kommen heutzutage nicht mehr so häufig vor, weil die Programmierer von Websites gewarnt werden, sie nicht zuzulassen, aber sie schleichen sich über Tage bis Monate hinweg ein, bis jemand das Problem meldet und die Hosting-Website das Problem der Umleitung behebt. Hacker und Phisher suchen nach Websites mit URL-Weiterleitungen, die für Phishing-Angriffe genutzt werden können.

Hinweis: Böswillige Umleitungen und andere ähnliche Tricks werden hier behandelt.

Beispiele für Umleitungsangriffe in der realen Welt

Im Folgenden finden Sie einige Beispiele aus der Praxis.

Beispiel UPS.com

Dieses aktuelle Beispiel hat mich dazu veranlasst, diesen Artikel zu schreiben. Mein Kollege, Erich Kron, kommentierte es in diesem Artikel. Im Wesentlichen schickte der Phisher eine E-Mail, in der er behauptete, vom United Postal Service (UPS) zu sein, weil eine Paketzustellung fehlgeschlagen war. Wir alle haben so etwas schon gesehen. Ziemlich alltäglich.

Aber in der E-Mail war eine URL enthalten, die mit ups.com begann (siehe unten).

malicious-url

Diese URL verweist auf die echte UPS.com-Website. Wenn man sich also nur diesen einen Datenpunkt ansieht, scheint es so, als würde man tatsächlich zu ups.com weitergeleitet. Es gibt sogar einen Screenshot (aus dem oben genannten Originalartikel), der zeigt, was angezeigt wird, wenn jemand auf den ups.com-Link klickt. Diese Webseite befindet sich nicht auf UPS.com.

Quelle: Express

Der Hacker verwendete die echte UPS.com-Website, fügte aber eine „onerror“-Weiterleitung ein, die der echten UPS.com-Website mitteilt, wohin sie den Benutzer weiterleiten soll, wenn der Link, der ihn ursprünglich zur echten UPS.com-Website führte, einen Fehler enthält. Der Phisher hat natürlich etwas in die URL eingefügt, das einen Fehlerzustand erzeugt. Wenn das potenzielle Opfer also auf den angegebenen Link klickt, wird es auf die echte UPS.com-Website weitergeleitet, die dann den „Fehler“ bemerkt und den in der onerror-Variable angegebenen Umleitungsanweisungen folgt. Dieser Teil ist eigentlich bei Millionen von Websites sehr, sehr üblich. Der Unterschied besteht darin, dass der getäuschte Benutzer nicht auf eine echte UPS.com-Webseite verwiesen wird (oder auf die Ursprungswebseite des Benutzers, falls es eine gab), sondern auf eine bösartige URL, die nichts mit UPS.com zu tun hat. Die bösartige Website sieht jedoch wie die echte UPS.com-Webseite aus (oder sieht ihr so ähnlich, dass der getäuschte Benutzer sie nicht groß in Frage stellt) und fordert den Benutzer dann auf, ein Dokument herunterzuladen. Das Dokument enthält Skripte, mit denen Malware gestartet wird.

Die bösartige Umleitungs-URL war Base64-kodiert. Die Funktion(atob) dekodiert die Base64-Kodierung zurück in ihren normalen Text (z. B. UTF-8), damit sie vom Browser des Benutzers ausgewertet werden kann. Die dekodierte URL im Klartext lautete: https://m.media-amazon[.]workers[.]dev/js, wobei die eckigen Klammern hinzugefügt wurden, um zu verhindern, dass Leser versehentlich auf den Link klicken und über den betrügerischen Link auf die betrügerische Website und die bösartige JavaScript-Datei geleitet werden. Insgesamt war dieses Beispiel einer bösartigen Weiterleitung äußerst raffiniert. Es wird behoben, indem UPS.com die onerror-Variable korrekter auswertet, damit sie nicht für bösartige Weiterleitungen verwendet werden kann.

Lösung

Machen Sie sich zunächst klar, dass die große Mehrheit der betrügerischen URLs keine gültigen, legitimen Markendomänennamen verwendet (z. B. microsoft.com). Schauen Sie sich also immer zuerst den Domänennamen in der URL an. Wenn er nicht auf eine gültige Marken-Website-Adresse verweist, können Sie ihn einfach als verdächtig markieren, ohne weiter darauf einzugehen. Wenn sie jedoch eine gültige Host-Domain-Adresse enthält, können Sie sich nicht auf diese eine, schnelle Prüfung zu 100 % verlassen. Sie sollten die E-Mail oder die Website, von der die URL stammt, etwas genauer untersuchen, um herauszufinden, ob die angegebene URL letztendlich auf eine gültige Domäne verweist oder nicht.

Zweitens: Stammt die URL aus einer unerwarteten E-Mail oder handelt es sich um ein Pop-up? Alles, was unerwartet kommt, sollte mit einem Anfangsverdacht behandelt werden, bis das eine oder andere ausgeschlossen ist. Wird ich in der unerwarteten E-Mail aufgefordert, auf eine URL zu klicken? Wenn ja, ist dies eine Aktion mit hohem Risiko. Wird ich in der URL oder E-Mail aufgefordert, eine Datei herunterzuladen oder ein Dokument zu öffnen? Beides ist eine äußerst risikoreiche Aktion. In welchem Kontext wird die Aktion durchgeführt? Wurden Sie schon einmal von der Quelle, die Sie dazu auffordert, zu dieser bestimmten Aktion aufgefordert? Wenn nicht, und Sie werden aufgefordert, etwas zu tun, was Sie noch nie zuvor getan haben, selbst wenn Sie glauben, dass die Aufforderung von einem seriösen Absender kommt, handelt es sich um eine hochriskante Handlungsaufforderung.

Wenn Sie auf den Link geklickt haben und statt auf der legitimen Domain zu landen, auf der Sie zu landen glaubten, landen Sie woanders, dann sollten Sie das als verdächtig betrachten. Leider gibt es viele seriöse Websites, Dienste und Marketing-Kampagnen, die Sie mit einem Köder ködern und Sie an einen anderen seriösen Dienst weiterleiten, der sich um Sie kümmert. Selbst wenn Sie auf einer anderen als der erwarteten Website landen, können Sie also nicht sicher sein, ob ein Link seriös ist oder nicht.

Auch hier gilt wieder, dass die Beweise überwiegen müssen. Wenn es sich um eine potenziell risikoreiche Aktion handelt und Sie noch nie darum gebeten wurden, dann zögern Sie und stellen Sie weitere Nachforschungen an, bevor Sie der vorgeschlagenen Aktion folgen. Noch besser ist es, wenn Sie dem vorgeschlagenen Link nicht folgen, sofern das Szenario dies zulässt. Gehen Sie stattdessen auf die Website des Hauptanbieters und beginnen Sie von dort aus. Im obigen Beispiel von UPS behauptet der Betrüger, dass eine Lieferung verschoben werden muss. Wäre dieser Antrag echt, könnten Sie zur echten ups.com gehen und dort denselben empfohlenen Antrag finden. Wenn das nicht der Fall ist, handelt es sich wahrscheinlich nicht um eine gültige Anfrage. Im Zweifelsfall sollten Sie die Finger davon lassen.

Wenn Sie wirklich glauben, dass die verdächtige Anfrage gültig sein könnte, öffnen Sie sie auf einem isolierten virtuellen Computer, der für eine solche Analyse eingerichtet wurde. Klicken Sie niemals auf einen verdächtigen Link auf Ihrem Arbeits- oder Produktionscomputer und hoffen Sie das Beste. Hoffnung schützt nicht vor böswilligen Hackern. Hoffnung schützt nicht vor Ransomware. Hoffnung schützt auch nicht vor Phishing. Aber ein wenig Nachforschung und Skepsis können helfen.

Verlassen Sie sich bei der Untersuchung einer E-Mail oder eines vorgeschlagenen Links immer auf die überwiegende Mehrheit der Beweise. Der Domänenname allein ist nicht genug. Und achten Sie auf diese bösartigen Weiterleitungen. Sie sind zwar nicht sehr häufig, aber es gibt sie. Kämpfen Sie weiter den guten Kampf!

Recommended Posts