paint-brush
Angriffe über Funk – Phreaking-HTML-Injectionvon@jvictors
1,133 Lesungen
1,133 Lesungen

Angriffe über Funk – Phreaking-HTML-Injection

von Jesse Victors7m2023/08/19
Read on Terminal Reader
Read this story w/o Javascript

Zu lang; Lesen

Am 13. Juli haben wir eine interessante Sicherheitslücke entdeckt. Eine bestimmte Webseite verfolgte digitale Radiosignale und zeigte ein fortlaufendes Protokoll dessen an, was der Sender hörte. Dies ist ein praktisches Tool, wenn Sie sich für solche Dinge interessieren. Schließlich ist es gut zu wissen, ob Ihre Anrufe gehört werden oder ob es laufende Gespräche gibt, an denen Sie teilnehmen möchten. Dieses Tool erfasste alles, was es hörte, und fügte es in die Webseite ein. Senden Sie eine Nachricht und ein paar Sekunden später wird sie dort angezeigt. Wenn die Nachricht HTML enthalten würde, würde diese auch auf der Webseite landen. Klassische HTML-Injection.
featured image - Angriffe über Funk – Phreaking-HTML-Injection
Jesse Victors HackerNoon profile picture
0-item

Das Telefonpfeifen der alten Schule ist zurück!


Na ja, fast, aber dieser Ton unten ist nicht so weit entfernt.


Am 13. Juli haben wir eine interessante Sicherheitslücke entdeckt. Eine bestimmte Webseite verfolgte digitale Radiosignale und zeigte ein fortlaufendes Protokoll dessen an, was der Sender hörte. Dies ist ein praktisches Tool, wenn Sie sich für solche Dinge interessieren. Schließlich ist es gut zu wissen, ob Ihre Anrufe gehört werden oder ob es laufende Gespräche gibt, an denen Sie teilnehmen möchten. Dieses Tool erfasste alles, was es hörte, und fügte es in die Webseite ein. Senden Sie eine Nachricht und ein paar Sekunden später wird sie dort angezeigt. Wenn die Nachricht HTML enthalten würde, würde diese auch auf der Webseite landen. Klassische HTML-Injection.


Wie funktioniert das?

Um einen Angriff wie diesen durchzuführen, braucht man überhaupt kein Internet – man braucht nur ein langes Stück Kabel. In unserer im Februar 2023 veröffentlichten Serie „Attacks Over the Air“ haben wir die drahtlosen Probleme besprochen, die eine Basketball-Anzeigetafel mit einem Controller mit einer Frequenz von 913 MHz mit sich bringt. In diesem Beitrag bewegen wir uns in der Frequenz ganz weit nach unten, in den Kurzwellen-Radiobereich. Dieser Angriff funktioniert bei 7,078 und 14,078 MHz.


Hier unten gibt es viele interessante digitale Signale, und JS8 ist eines davon. JS8 ist ein beliebtes Tastatur-zu-Tastatur-Chat-Tool für Amateurfunker. Es ist absolut hervorragend darin, direkte Gespräche über große Entfernungen und unter sehr schlechten Verbindungsbedingungen zu ermöglichen. JS8 basiert selbst auf FT8, einem äußerst beliebten Tool zum Herstellen einfacher Kontakte zwischen Stationen, die sich kaum hören können. Tag und Nacht sind FT8 und JS8 ständig im Einsatz.


(Die letzten 24 Stunden des JS8-Verkehrs auf 14,078 MHz)


Bei Signalen im Kurzwellenband passieren mehrere seltsame Dinge. Die Frequenz ist so niedrig, dass in 100 Meilen Höhe über uns die E- und F-Schichten der Ionosphäre der Erde beginnen, das Funksignal wieder zurück zum Boden zu reflektieren. Die Signale springen mehrmals zwischen der Erde und dem Boden hin und her, als würde man einen Stein über das Wasser hüpfen lassen. Dadurch können wir nachts kommerzielle AM-Sender auf der anderen Seite des Planeten hören. Tagsüber funktioniert dieser Bounce auch bei höheren Frequenzen und ermöglicht so die Kommunikation über große Entfernungen. Mein Hinterhofsender und die Website-Station sind 674 Meilen voneinander entfernt. Mit einem Sprung lässt sich diese Distanz problemlos zurücklegen.

Wie greift man also eine Website mit einem Kurzwellensignal an?

JS8-Nachrichten werden im ASCII-Text erstellt, ausschließlich in Großbuchstaben. Die meisten Nachrichten werden an große Gruppen gesendet, wie z. B. Skywarn, JS8Chess oder, um auf alle zu verweisen, einfach ALLCALL. Anschließend kann die Nachricht so ziemlich alles sein. Zuerst erstellen wir die HTML-Payload im Editor. Wir müssen unser Amateurfunk-Rufzeichen zur Identifizierung legal angeben (ein Schritt, der von einem echten Angreifer ignoriert wird) und am Ende sieht unsere letzte Nachricht so aus:


KJ7YLS: @TEST <DIV STYLE="WIDTH: 500PX;HEIGHT:100PX;COLOR:RED;">HTML INJECTION!</DIV>

Wir sind jetzt zur Übertragung bereit. Die JS8-Software wandelt diesen Text in einen Binärtext um, fügt eine Vorwärtsfehlerkorrektur hinzu und moduliert das Ergebnis mithilfe der Gaussian Frequency Shift Keying (GFSK). Das Endprodukt klingt hörbar nach seltsamen Pfeifgeräuschen. Wenn wir den Sound mit Audacity öffnen und ein Spektrogramm öffnen, sieht es so aus:



Bei genauerem Hinsehen erkennt man, wie die GFSK-Modulation langsam von einer Frequenz zur anderen übergeht. Außerdem bleibt es bei jeder Frequenz für eine bestimmte Zeitspanne erhalten. Hier werden acht verschiedene Frequenzen verwendet und somit hat jedes Symbol acht verschiedene Zustände. Dadurch kann jedes Symbol jeweils drei Bits übertragen. Dies wird durch einige Beschriftungen veranschaulicht:



Das Pfeifgeräusch können wir dann in das Mikrofon eines Funksenders senden. Wie die meisten Amateur- und Militärsignale wird der Ton mithilfe der oberen Seitenbandmodulation übertragen, bei der es sich um einen Abschnitt eines AM-Rundfunksignals handelt. JS8-Nachrichten sind auf mehreren Frequenzen standardisiert und unser Ziel hört auf 7,078 MHz und 14,078 MHz. Wir stellen das Radio auf eine der beiden Frequenzen ein und senden den Ton mit einer Leistung von 20 Watt an ein 16-AWG-Kabel etwa 30 Fuß über der Luft. Das Signal strahlt in die Luft, wird von der Ionosphäre reflektiert und von ihrer Antenne empfangen. Ihre JS8-Software kehrt den Prozess um und ruft die ASCII-Nachricht ab. An diesem Punkt sehen wir das Problem.

Die Website (Link wird in diesem Artikel aus Respekt vor dem Autor zurückgehalten) protokolliert den JS8-Verkehr. Unter der Haube steckt JS8Net , ein nützliches Python-Tool, das direkt mit der API der JS8-Software kommuniziert. Im Repository erfasst das Skript monitor.py die JS8-Nachrichten und platziert sie auf der Website. Zum Zeitpunkt des Schreibens enthält es in Zeile 859 die folgenden Codezeilen:


 # Text j['text']=j['stuff']['params']['TEXT'] key=str(j['stuff']['time']) j['id']=':'.join([fmcall,tocall,key,str(j['freq'])]) traffic[key]=json.dumps(j)


j['stuff']['params']['TEXT'] ist die ASCII-JS8-Nachricht, die von Collector.py abgerufen wird, die von der API der JS8-Software abgerufen wird. Nach diesem Schritt wird der Text in Traffic[key] mithilfe von Javascript auf der Seite platziert. Diese Schritte sind in Ordnung. Das Problem tritt bei der Änderung des Kontexts auf, da davon ausgegangen wird, dass der JS8-Verkehr, der bereits vollständig von der JS8-Software verarbeitet wurde, einsatzbereit ist und den Kontext der Webseite nicht beeinträchtigt. Das ist das Verhalten, das wir dann ausnutzen können.


Von Anfang bis Ende sieht unser Angriff so aus:


Wenige Minuten später wird unsere Nachricht auf der Website protokolliert...


Das Endergebnis ist größtenteils kosmetischer Natur. Da es sich um eine öffentliche Seite handelt, gibt es keine zu stehlenden Sitzungscookies oder zu manipulierenden Steuerelemente. Gespeichertes XSS ist ebenfalls eine echte Möglichkeit, aber nach einem frustrierenden Morgen mit dem Versenden vieler, vieler zeitaufwändiger Payloads (das Versenden jeder JS8-Nachricht dauert mehrere Minuten) konnten wir Javascript nicht zum Laufen bringen, das auf der Seite ausgeführt werden konnte. Ich vermute, dass die JS8net-Software versehentlich viele der Schlüsselzeichen und -wörter blockiert hat und unsere Problemumgehungen scheinbar nicht funktioniert haben.


Dennoch hat sich Burp Suite hier als nützlich erwiesen. Die Ionosphäre war an diesem Tag kooperativ und reagierte ziemlich gut mit den Signalen. Von anderen Tools wusste ich, dass Stationen in anderen Ländern JS8-Verkehr aus den USA hörten. Meine nächste Nutzlast war also

KJ7YLS: @ALLCALL <img src="http://727k2w1hfoamqewpm7rpiocu0l6cu2ir.oastify.com" alt="@HB DN13">

Diese URL verweist auf einen DNS- und HTTP-Listener, der vom Collaborator-Tool von Burp Suite ausgeführt wird und das wir häufig bei Penetrationstests verwenden, um Out-of-Band-Informationslecks zu finden. Das war nicht anders. Innerhalb weniger Minuten wurde der DNS- und HTTP-Verkehr von Benutzern, die die Seite in Chile besuchten, vom Collaborator-Server aufgezeichnet. Ich habe mir auch die Seite angesehen, um die Injektion zu überprüfen, und wurde ebenfalls protokolliert.


Das war ungefähr so weit, wie ich mit der Injektion ethisch gesehen wollte. Ich habe das Problem dem Eigentümer der Website, Jeff, gemeldet und Vorschläge zur Behebung gemacht. Am nächsten Tag meldete er sich bei mir und sagte:


Ich arbeite selbst im Sicherheitsbereich (ich mache Forschung und Entwicklung für ein Netzwerksicherheitsunternehmen in der Bay Area), aber ich muss zugeben, dass die JS-Übermittlung per Funk, um eine Website zu hacken, völlig außerhalb meines Radars lag.

Während ich darauf wartete, dass der Patch live ging, dachte ich über ein paar Zeilen aus der JS8Net-README-Datei nach:


 It's important to note that this part of the software is still very much in the development stage, and may have critical vulnerabilities that make exposing the exposed services to the open Internet a Very Bad Idea. While it certainly will work, it's intended for protected, internal LAN use at this time.


Ehrlich gesagt ist dies im Allgemeinen eine hervorragende Warnung, insbesondere für Projekte, die noch im Gange sind und noch nicht gründlich getestet wurden. Schwachstellen sind an dieser Stelle ein „unbekanntes Unbekanntes“, aber der Autor dachte in erster Linie an die exponierten Listener und APIs in seiner Software. Allerdings haben wir ein etwas anderes Problem ausgenutzt. Die README-Datei warnt davor, dass der Dienst in einem LAN ausgeführt werden sollte und dies tatsächlich andere vor HTML-Injektionen und Schädigung der Webseite schützen würde. Allerdings würde eine Nutzlast mit Collaborator-Nutzlasten auch die öffentliche IP-Adresse aller Personen preisgeben, die die Seite in ihrem privaten LAN betrachten, sodass dies etwas schwieriger zu beheben ist.

Kurz gesagt handelt es sich dabei um ein Funksignal, das eine Webseite im Internet angreift. Ein Angreifer muss nicht mit VPNs, Tor oder Botnetzen herumspielen, um zu versuchen, seine Identität im Internet zu verbergen. JS8 ist so effektiv beim Extrahieren von Nachrichten, die 24 dB unter dem Grundrauschen liegen (das Pfeifen ist bei diesem Pegel buchstäblich nicht hörbar), dass nur sehr wenig Strom benötigt wird, um entfernte Stationen zu erreichen. Ein Watt Sendeleistung kann bei guten ionosphärischen Bedingungen von Küste zu Küste in den USA übertragen werden. Ein Angreifer könnte überall auf der Welt sein. Es genügt eine Burst-Meldung, daher wäre auch die Peilung schwierig. Ich denke, dass man mit so etwas so gut wie nicht auffindbar sein kann.


Zeitleiste:

  • 13. Juli: Das Problem wurde entdeckt, Jeff gemeldet und bei MITRE ein CVE beantragt
  • 14. Juli: Jeff antwortet.
  • 22. Juli: Jeff wendet einen Patch für JS8Net auf Github an.
  • 25. Juli: Der Patch wird auf der Website veröffentlicht.
  • 18. August: Der Blogbeitrag wird veröffentlicht.