Offenes Relay bei Telefonie

Wer heute ein offenes Mail-Relay ins Internet stellt wird sehr bald einen Missbrauch durch Spammer feststellen, die so ihre Spuren verwischen. Sie kostet es aber "nur" Bandbreite" und Reputation, d.h. Sie bekommen ihre eigenen Mails auch nicht mehr los, wenn ihre IP-Adresse als "Open Relay" gebrandmarkt ist. Wer eine VoIP-Anlage oder auch eine ISDN-Vermittlung am Internet betreibt, muss aber besser aufpassen, da die bösen Jungs hier gerne ihre eigenen teuren Hotline-Nummern anrufen um auf ihre Kosten Geld zu verdienen. Das kann schnell hohe Beträge erreichen.

Unsicherer Admin-Zugang und Anwendereinstellungen

Das erste Einfallstor hat gar nicht sofort etwas mit der Adressierung bei einem Anruf zu tun sondern basiert darauf, dass sich jemand von extern oder über einen internen Trojaner Zugang zur Verwaltungsschnittstelle ihrer Vermittlungsanlage verschafft und dort über die Anlagenmerkmale eine Weiterleitung einrichtet. Wer z.B. bei einem Endanwender eine permanente Weiterleitung zu einer teuren "Service-Nummer einrichtet, kann von extern diese Kosten generieren.

Das gleiche kann natürlich auch den Anwender selbst betreffen. Wer heute auf dem PC mit einem "SoftClient" arbeitet, der vielleicht noch entsprechende Schnittstellen für eine Fernkonfiguration anbietet, kann ebenfalls Opfer werden. Zumindest wenn es den ersten Schadcode gibt, der einmal ausgeführt, bei den Anwender eine Rufweiterleitung einrichtet. Das geht sogar mit "Tischtelefonen", wenn diese z.B. per CTI-Funktion angebunden sind. Denkbar wäre auch, wenn der Schadcode als Dialer einfach eine Verbindung initiiert. In allen Fällen zahlen Sie die Rechnung und der angerufene Dienstleister teilt sich die Einnahmen mit dem Provider.

Sie sollten also nicht nur auf "das böse Internet" schauen sondern auch intern einen Blick auf ihre Systeme werfen. Standard-Kennworte auf Systeme sind immer schlecht, auch wenn diese offiziell nie von extern erreichbar sein sollten. Die Praxis zeigt, dass es doch immer mal wieder gelingt.

Port 5060/5061 im Internet

Der einfachste Fehler ist natürlich die unsichere Veröffentlichung eines SIP-Servers. Sie könne ja mal ihre Firewall betrachten, welche Endpunkte im Rahmen eines PostScans auf ihrem System den Port 5060 oder 5061 ansprechen. Dies ist der "übliche" SIP-Port und auch ein Skype for Business Edge-Server lauscht auf diesem Port.

Jedes "gut konfigurierte" System sollte einen "INVITE" als Start einer Verbindung natürlich nur zulassen, wenn sich der Absender auch "authentifiziert" hat. In der Hinsicht gleicht der Ansatz dem eines Mailservers, über den die Anwender ihre Mails zur Zustellung einliefern. Beide Systeme sind gefährdet, wenn die Anmeldedaten nicht sonderlich "sicher" sind. Da gibt es natürlich mehrere Einfallstore

  • Standard-Benutzer mit Standardkennworten
    Es ist leider zu oft der Fall, dass ein SIP-System mit vordefinierten Benutzern betrieben wird und auch das Standard-Kennwort des Herstellers nicht geändert wurde. Da brauchen wir dann nicht mehr viel zu sagen.
  • Benutzer mit schwachen Kennworten / Systeme ohne Brute-Force-Schutz
    Das zweite Risiko sind Benutzer, deren Anmeldename (UPN = SIP-Adresse = SMTP-Adresse) bekannt sind und die Kennworte nicht besonders gut sind. Gerade bei "Anmelden auf einem Telefon" wird gerne eine Extension und PIN verwendet. Wenn hier der Service nach einigen Fehlversuchen nicht die Anmeldung per PIN unterbindet und alarmiert, dann hat der Angreifer sehr bald gültige Zugangsdaten
  • Unverschlüsselter Verkehr
    Sehr oft wird SIP auch noch ohne TLS betrieben. Das ist heute nicht mehr tolerierbar, denn dann werden Anmeldedaten meist auch nicht besser geschützt und es reicht eine Anmeldung auf dem Smartphone oder Notebook an einem öffentlichen Hotspot.

Aber neben den "authentifizierten" Benutzern gibt es natürlich auch Systeme wie Skype for Business, die z:.B. für die Funktion "Federation" auch SIP-Pakete ohne Authentifizierung annehmen. Bei Skype for Business wird natürlich Wert auf TLS und hier sogar auf MTLS gelegt, so dass nicht "jeder" einmal mal ein INVITE abliefern kann. Aber mit dem passenden öffentlichen und vertrauenswürdigen Zertifikat könnte auch hier jemand einen INVITE senden. Dann liegt es an dem SIP-Router dahinter zu entscheiden, ob der Absender legitimiert ist, das Ziel zu erreichen. Das macht Skype vor Business schon fehlerfrei. Zumindest ist mir noch nie zu Ohren gekommen, dass jemand anonym von Extern einen INVITE zu einer TEL-URI machen konnte. Skype for Business unterwirft jeden INVITE einer Prüfung gegen die Voice Policies des Absenders mit den passenden "PSTN Usages" um die erlaubten Voice Routen zu ermitteln. Voice Policies können neben Benutzern aber nur SIP-Trunks bekommen. Daher ist ein Anruf über Federation gar nicht möglich.

Unsicheres TrunkRouting

Aber ein eingehender Anruf über einen SIP-Trunk zum Skype for Business Mediation Server kann durchaus eine "Voice Policy" bekommen. Diese Konfiguration ist sinnvoll, wenn eine externe Anbindung zuerst bei Skype for Business landet und dann auch über die Plattform zu einem anderen System, z.B. CSAnalogDevice, weitergegeben werden soll. In diesem Fall ist es aber wichtig eine eigene Voice-Policy für diesen Trunk einzurichten, die dann auch nur die ausgewählten Ziele zuläst. Wer hier dem "Trunk" quasi die gleichen Rechte wie einem Benutzer einräumt, kann die Tür schon zu weit öffnen. Dann fehlt nur noch eine etwas offene Normalisierungsregel und der Anruf von Extern wieder direkt wieder nach Extern weiter geleitet.

Unsicheres Gateway-Routing

Es muss aber nicht Skype for Business sein. In den meisten Fällen kommt eine "Amtsleitung" als ISDN-Leitung oder SIP-Trunk in die Firma und terminiert auf einem Gateway oder Session Border Controller. Das Gateway leitet den Anruf an Skype for Business oder einen SBC weiter. Wer neben Skype for Business noch eine TK-Anlage per SIP anbindet, wird oft die folgende Konstellation habem

Am Beispiel eines Audiocodes-Gateways, welches per ISDN sowohl am Amt als auch eine TKL-Anlage bedient und daher Telefonate zwischen Amt und alter TK einmal über "localhost" eine Schleife drehen, möchte ich eine problematische Konfiguration aufzeigen. Hier ein Ausschnitt:

Index Beschreibung Quelle Dest prefix AddPrefixString RemovePrefixDigits Destination
1

Normalisierung TEL2IP
Die Zielrufnummer des eingehenden Anrufs vom Amt wird auf E.164 umgesetzt.

-1

*

+495251304

 

-

2

Route TEL2IP
Alles was von "ISDN" kommt, wird auf IP umgesetzt.

-1

*

 

 

Localhost

3

Route IP2Tel
Rufe an die internen Nummern gehen zur TK-Anlage

-1

+495251304[500-799]#

 

 

TK

4

Route IP2Tel
Alle anderen Rufe sind dann ja Amtsnummern

-1

*

 

 

Amt

5

Ausgehend Normalisierung IP2Tel
Die TK-Anlage versteht kein E.164. Also schneidet man ihr die Nummern weg.

-1

+495251304*

 

13

 

Der echte Regelsatz hat natürlich noch ein paar weitere Regeln um z.B. per LDAP-Routing die Anrufe an Skype for Business-Anwender direkt zu Skype for Business zu routen. Der besseren Übersichtlichkeit wegen habe ich die aber weggelassen. Aber auch so ist zu sehen, was im schlimmsten Fall passiert.

  1. Ein Angreifer wählt die 05251304613090012345678
  2. Die Amts-Vermittlung sendet mir die "Durchwahl" 613090012345678
  3. Diese Nummer wird normalisiert
    Die Zeile 1 macht aus der Zielnummer wieder eine E.164-Nummer "+495251304613090012345678"
  4. Diese Nummer wird per LDAP nicht gefunden und durch die Regel 2 via "Localhost" geroutet
  5. Ab nun ist es ein IP2TEL Call
    Da die Regel 3 aber etwas enger gefasst ist, damit nur die gültigen Nebenstellen zur TK-Anlage gehen, greift sie nicht bei dieser "langen" Nummer
  6. Regel 4 kommt nun zum Tragen
    Die Anruf wird Richtung AMT geroutet
  7. Regel 5 sorgt dann wieder für die Verwandlung von E.164 zu einer ISDN-Nummer
    Eigentlich sollte diese Regel nur greifen, wenn es zur TK-Anlage geht aber sie ist so angelegt, dass Sie immer greift, wenn diese E.164-Zielnummer gewählt wird und es "Richtung ISDN" geht. Leider ist die Regel nicht auf die Verbindung zur TK-Anlage beschränkt. Aus der Zielnummer "+495251304613090012345678" werden die ersten 10 Stellen abgeschnitten.
  8. Gewählt wird nun also die 090012345678
    Damit ist dem Missbrauch Tür und Tor geöffnet auf Kosten des Betreibers teure Ferngespräche zu führen oder sogar "Premium"-Nummern anzurufen und sich in krimineller Manier die Erlöse zu teilen.

Dies ist nur ein Beispiel, wie knifflig eine Konfiguration eines Gateway sein kann und welche Fallstricke lauern. Das "Problem" in dem Beispiel ist, dass der "letzte Weg nach Intern" zu eng gefasst war und daher auch externe Anrufe über "Loopback" wieder raus geroutet werden konnten. Anstatt aber nun an den Zielnummern zu schrauben sollten Sie besser überlegen an der Quelle anzusetzen. Der Eintrag "-1" bedeutet einfach nur, dass die Regel unabhängig von der Quelle angewendet wird. Hier kann man schon mal filtern und auch in die Gegenrichtung sind Filter möglich. Natürlich wird dadurch so eine Liste der Routingregeln und die Normalisierungstabelle länger aber das "sparen" von Zeilen durch Zusammenlegung von dem Anschein nach identischen Funktionen kann auch daneben gehen.

Schutz durch Limits

Niemand kann von sich behaupten fehlerfrei zu arbeiten. Mein Wahlspruch ist hier: "Wer was tut, kann Fehler machen, Wer nicht tut, macht auf jeden Fall etwas falsch". Dennoch gibt es verschiedene Vorkehrungen eine Konfigurationslücke gesondert abzusichern. Nicht immer ist eine offene Konfiguration offensichtlich. Wir kennen das Thema ja als "Open Relay" bei den SMTP-Servern seit vielen Jahren und die wenigsten dieser Systeme dürften absichtlich so betrieben werden. Für Telefonie/VoIP gibt es aber die gleichen Fehlerfälle und je mehr SIP-Trunks eingerichtet werden, desto mehr Systeme werden wir im Internet finden, die auf Port 5060/5061 eingehende SIP-Anfragen annehmen und sicher auch durchprobiert werden. Schauen Sie doch mal auf ihrer Firewall nach Systemen, die bei ihnen diese Ports abprüfen. Sie können auch gerne mal eine kleine SIP-Simulation laufen lassen um zu sehen, welche "Rufnummernmuster" so versucht werden.

  • Testfälle
    Nach der Installation ist natürlich nachzuweisen, dass die geforderten Funktionen erfüllt sind. Dazu zählt natürlich eine Testreihe hinsichtlich verschiedener Anrufziele und Quellen. Genauso sollten Sie natürlich auch entsprechende "nicht erlaubte Nummern" prüfen, ob diese auch wirklich gesperrt sind
  • lokale Block-Regeln
    Wenn Sie also Firma bestimmte Nummerngassen (0137, 0900) nicht benötigen oder bestimmte teure ferne Länder nicht erreichbar sein müssen, dann können Sie diese natürlich auf dem Gateway schon wegblocken. Hinweis: Es reicht nicht diese Nummern über Skype for Business "Voice Policies" gar nicht erst zu erlauben.
  • Provider-Sperren
    Auch die Telefonprovider, die ihnen letztlich die Gespräche in Rechnung stellen, können Nummerngassen sperren. Das ist ein weiterer Schutz, der auch von ihnen intern (oder einem Trojaner oder Hacker) nicht so einfach umgangen werden kann. Wer sagt ihnen denn, dass ihr Kennwort für das Gateway ausreichend sicher ist.
  • Provider-Limits
    Wenn Sie nicht gleich komplette Nummerngassen "sperren" wollen, dann fragen Sie ihren Provider einmal, welche "weichen" Grenzen er bezüglich der Rechnung umsetzen kann. Sie wissen in der Regel schon, wie viele Kosten pro Monat oder pro Tag auflaufen und vielleicht lassen sich hier auch Grenzwerte einziehen.

Das verhindert zwar nicht den Missbrauch aber reduziert das Schadenspotential und die Kosten.

Monitoring

Unabhängig davon können Sie natürlich auch lokal weitere Hilfsmittel einsetzen, um Missbrauch frühzeitig zu erkennen. Leider ist die Skype for Business QoE-Datenbank keine passable Quelle, da hier gerade die Anrufe gar nicht erfasst werden, die durch eine Fehlkonfiguration der Anbindung ans Amt stattfinden. Die aussagefähige Quelle für solche Reports und Überwachungen ist das Gerät, welches die Verbindung zum Carrier herstellt. Wenn Sie hier alle ein-. und ausgehenden Verbindungen protokollieren, haben Sie schon mal eine gute Datenbasis zur Kontrolle der Abrechnung.

Interessant wird dies, wenn Sie die Aktivitäten quasi in "Realtime" überwachen. Interessant sind hier z.B.: die Anrufe pro Zeiteinheit abhängig von der Tageszeit oder auch die Gesprächsdauer pro Tageszeit. Allerdings gibt es hier zwei Missbrauchsszenarien:

  • Kurzfristiger Gewinn
    Ein Täter versucht in möglichst kurzer Zeit Gewinn aus der vorgefundenen Situation zu schlagen. Er wird dazu sogenannte "Service/Mehrwertnummern" anrufen, die ihnen in Rechnung gestellt werden. Diese Ziele sind dann meist im Ausland, wo der Täter zugleich Anbieter dieses "Service" ist und damit an den Einnahmen beteiligt ist.
  • Langfristiger Vorteil
    Auf fremde Kosten zu telefonieren oder bei einem Anruf seine Nummer zu verschleiern kann auch dazu führen, dass jemand nur gelegentlich ihren "Service" nutzt. Das wird dann eher nicht auffallen, wenn Sie nicht akribisch die Rufnummern prüfen. Aber lange hält das nicht an, da so ein offenes System dann irgendwann wieder von der ersten Gruppe an Tätern gefunden wird.

Auf jeden Fall tun sie gut daran die "Counter" ihres Systems zu überwachen und ggfls. einen Alarm zu generieren, um in den ebenfalls mit erfassten Verbindungsprotokollen nach der Ursache zu suchen.

Wer die Überwachung zur Perfektion treiben will, kann natürlich die ausgehenden Anrufe anhand der Rufnummer und Dauer direkt auf einen "Kostenfaktor" umrechnen und daraus Alarmschwellen generieren. Die Auswertung nach Zielen und Anrufern mit Kosten wird in vielen Firmen ja für die Kostenverrechnung heute schon gemacht. Allerdings erfolgt das bislang eher einmal im Monat und nicht zeitnah.

Weitere Links