Schwere Sicherheitslücke bei Yealink Telefonen

  • Guten Morgen,

    hat schon irgendwer Informationen seitens Starface bekommen wie mit der aktuellen Sicherheitslücke bei Yealink Telefonen umgegangen wird?

    https://www.heise.de/ct/artikel/VoI…kt-4654580.html

    Gruß
    Thomas

    Nichts gehört bisher. Die Meldung ist aber auch erst wenige Stunden alt. Allerdings soll laut Artikel ein Provider bereits tätig geworden sein, würde mich mal interessieren, wer da so schnell reagiert hat. Hab selbst ein paar Yealinks über Starface autoprovisioniert, das hinterlässt schon ein mulmiges Gefühl, dass die Daten eventuell abgesaugt werden könnten. Wenn ich den Artikel richtig verstehe, betrifft das nur Telefone, die über Yealink selber autoprovisioniert werden. Ob Starface bei der Autoprovisionierung auf diesen Service zurückgreift, sieht man ja leider nicht. Ein Statement seitens Starface wäre da ja mal hilfreich.

    Edited once, last by FrankB (February 7, 2020 at 10:12 AM).

  • Wir können euch seitens STARFACE aktuell folgenden Stand mitteilen:

    Der Fehler muss zuallererst durch Yealink behoben werden. Wir als STARFACE können hier nur begrenzt tätig werden. Ein anderer Hersteller hat aus einem Zero-Touch-Provisioning jetzt ein Seven-Touch-Provisioning gemacht, bei dem jedes Telefon angefasst werden muss. Das möchten wir vermeiden.

    Aktuell sind nur Telefone betroffen, die an einer Cloud betrieben werden oder wurden. Nur diese sind am Yealink Autoprovisioning Service registriert. Alle an einer lokal betriebenen Telefonanlage verwendeten Telefon sind unseres Wissens nicht betroffen.
    Für alle an einer Cloud-PBX verwendeten Telefone werden wir in Kürze ein Update bereitstellen, das alle Bestandstelefone absichert. Ein Angriff auf neu zu registrierende Telefon ist durch zeitliche Begrenztheit extrem unwahrscheinlich und wird durch hoffentlich bald von Yealink durchgeführte Maßnahmen noch weiter eingeschränkt.

    Beim Zeitrahmen für das Update sprechen wir nicht von Wochen, sondern von Tagen, abhängig von unserer Qualitätssicherung.

  • Das Problem betrifft nicht die Telefone!

    Es handelt sich um ein Thema der Provisionierungs- und Redirectionserver, die dazu gebracht werden können, Zugangsdaten und weitere Informationen herauszugeben.
    Aus diesem Grund rate ich regelmäßig hier im Forum dazu, den Autoprovisionierungsport 50080/TCP nicht von Außen erreichbar zu machen!

    Die STARFACE selbst validiert die Anfragen jedoch sehr gut und missbräuchliche Anfragen führen zur Sperrung der anfragenden IPs.
    Lediglich Angreifer, die durch externe Lücken in den Besitz der Cloud-URL sowie der Telefon-MAC-Adresse gelangen, haben eine Chance.

    MAC-Adressen lassen sich jedoch leicht gegenüber Redirectionservern erraten, denn nur bei einer richtigen MAC, bekommt man die entsprechende Autoprovisionierungs-URL. Damit kann man diese MAC dem Zielsystem auch korrekt mitteilen.

    Sollte ein Angreifer in den Besitz gültiger Zugangsdaten gelangen, gibt es seit 2015 für die STARFACE das Modul AntiFraud: https://wiki.fluxpunkt.de/display/FPW/AntiFraud


    Nachtrag:
    Wir empfehlen, für exponierte Anlagen außerdem die Deaktivierung der Einstellung "Neue Telefone automatisch aktivieren":

    provactivate.png

    Für bereits bestehende Yealink-Telefone müßte die Autoprovisionierung als Workaround deaktiviert oder AntiFraud eingesetzt werden.

  • Das Problem betrifft nicht die Telefone!

    Sollte ein Angreifer in den Besitz gültiger Zugangsdaten gelangen, gibt es seit 2015 für die STARFACE das Modul AntiFraud: https://wiki.fluxpunkt.de/display/FPW/AntiFraud

    Nachtrag:
    Wir empfehlen, für exponierte Anlagen außerdem die Deaktivierung der Einstellung "Neue Telefone automatisch aktivieren":

    provactivate.png

    Für bereits bestehende Yealink-Telefone müßte die Autoprovisionierung als Workaround deaktiviert oder AntiFraud eingesetzt werden.

    Wenn ihr das Thema anscheinend seit 2015 erkannt habt und Starface anscheinend ja auch schon länger davon weiß und Yealink ein empfohlener Premium Partner ist, warum besteht dann heute fast 5 Jahre später immer noch ein Problem, das theoretisch alle Starface Cloud Anlagen betrifft, die nicht zusätzlich Euer Modul installiert haben?

  • Wenn ihr das Thema anscheinend seit 2015 erkannt habt und Starface anscheinend ja auch schon länger davon weiß und Yealink ein empfohlener Premium Partner ist, warum besteht dann heute fast 5 Jahre später immer noch ein Problem, das theoretisch alle Starface Cloud Anlagen betrifft, die nicht zusätzlich Euer Modul installiert haben?

    Weil es

    a) damals ein snom-Problem war, das zur Entwicklung des Moduls geführt hat,
    b) wir nicht wissen, wie der Yealink-Redirection-Server die Echtheit eines Telefons verifiziert (Black Box) und wir deshalb
    c) eine davon unabhängige 2-Faktor-Authentifizierungslösung gebaut haben und
    d) wir einfach etwas paranoider in Bezug auf Sicherheit sind
    e) und wir nicht mehr machen können, als eine Lösung anzubieten. Warum habt ihr das nicht für all eure Kunden bestellt und einfach zu den Anschaffungskosten einer Lösung hinzugerechnet?

    Unser Modul wurde in den letzten Jahren nicht wirklich ernst genommen -- die Gefahr schien den meisten zu abstrakt.
    Außerdem ist nicht nur STARFACE als Cloud-Anbieter betroffen. Die meisten Anbieter stehen hier vor der selben Herausforderung, die vermutlich nur durch eine Mehrfaktorlösung und Abkehr von Zero-Touch-Provisionierung zu lösen ist.

  • Wenn ihr das Thema anscheinend seit 2015 erkannt habt und Starface anscheinend ja auch schon länger davon weiß und Yealink ein empfohlener Premium Partner ist, warum besteht dann heute fast 5 Jahre später immer noch ein Problem, das theoretisch alle Starface Cloud Anlagen betrifft, die nicht zusätzlich Euer Modul installiert haben?

    Das Modul von Fluxpunkt schafft eine Sicherheit gegen den abstrakten Fall, dass jemand auf welche Art und Weise auch immer die SIP Credentials erfahren hat.

    Dass Yealink nun eine konkrete Lücke im Autoprovisioning Service hat, liegt außerhalb unseres Einflussbereichs. Yealink arbeitet jedoch zweistufig an der Behebung und wird die Sicherheitslücke schließen.
    Parallel dazu werden wir in Kürze ein Service Release veröffentlichen, dass die Lücke so wie damals bei Snom auch auf STARFACE-Seite schließt.

  • Hinweis: Wir haben soeben Version 6.7.1.14 als Service Release veröffentlicht.

    Dieses geplante Service Release enthält zahlreiche Anpassungen und Fehlbehebungen. Zusätzlich sichern wir die Lücke im Yealink Autoprovisioning Service ab.
    Wir empfehlen, alle STARFACE-Cloud-Systeme mit Yealink-Telefonen auf diese Version zu aktualisieren.

  • AntiFraud wurde soeben für STARFACE 6.7.1 veröffentlicht und schützt weiterhin auch dann, wenn einem Angreifer die SIP-Zugangsdaten bereits in die Hände gefallen sind.

    Außerdem verlangt AntiFraud bei der Anmeldung an neu provisionierten Telefonen (egal ob snom, Yealink oder anderer Hersteller) eine PIN-Authentifizierung (2FA) bevor der Anmeldevorgang ausgeführt wird und dem Telefon sensible Daten (Ruflisten, Funktionstasten, Adressbuchdaten) übermittelt werden.

    Mehr unter: https://wiki.fluxpunkt.de/display/FPW/AntiFraud

    P.S.: Aus gegebenem Anlass wurde das Modul im Preis gesenkt (von 249 € auf 79 €).

  • Hinweis: Wir haben soeben Version 6.7.1.14 als Service Release veröffentlicht.

    Dieses geplante Service Release enthält zahlreiche Anpassungen und Fehlbehebungen. Zusätzlich sichern wir die Lücke im Yealink Autoprovisioning Service ab.
    Wir empfehlen, alle STARFACE-Cloud-Systeme mit Yealink-Telefonen auf diese Version zu aktualisieren.

    Wie sieht es mit einem Script-basiertem Update für alle Cloudsysteme aus die sich im Support-Fenster (ab 6.4.34) befinden? Wir sind nicht in der Lage die Menge unserer Cloudsysteme in kurzer Zeit alle auf die Version 6.7.1 zu aktualisieren. Zudem müssen zum Teil Module von Drittherstellern aktualisiert werden, da diese nur für die jeweiligen Versionen gelten. Das ist ein riesiger Aufwand...

  • Gerade kam eine Mail von Yealink bezüglich der RPS Services. So wie es aussieht wird das Sicherheitsleck seitens Yealink ab morgen 12.02.2020 geschlossen sein. Hier der Text dazu:

    【When is the update scheduled?】
    This RPS update is scheduled at 15:00PM~16:00PM (UTC+8), February 12, 2020. All the RPS services will still be up and running during the update.

    【What have been updated?】
    To improve the overall quality and security of RPS service offering, Yealink has updated the RPS Service Policy as below:
    1. Yealink RPS service is mainly designed for brand-new phones, and we strongly recommend customers to use it only for the initial setup process. For the initial setup, the user experience of RPS service remains the same.
    2. For existing phones which have been provisioned via RPS once, an additional two-factor device authentication is now required and implemented when these phones request for RPS service again. If the authentication fails, the phones will be blocked from accessing RPS service.

    【What may occur to your customers?】
    When you are doing a factory reset to reconfigure an existing phone via RPS service again, you may get a prompt on phone screen asking you to enter the last 5 digits of the Serial Number of this device. Please follow the instructions to enter the digits to finish the authentication. Otherwise, the device will not be able to connect to RPS.

    【What we can do to help customers?】
    Currently we provide two options as follows to help customers:
    Option #1: Users can enter the last 5 digits of the phone’s SN when prompted for it after factory resetting the phone to complete the two-factor authentication.
    Option #2: If your customer is unable to find or enter the SN by themselves, you may unlock the device via RPS Admin Portal.

    【How to contact Yealink if you have any further concern?】
    Should you have any further question or concern, please reach out to us at rps.feedback@yealink.com. Our specialists will be more than happy to accommodate you as soon as possible within 24 hours.

    Yealink Management Cloud Service
    http://www.yealink.com

  • Gerade kam eine Mail von Yealink bezüglich der RPS Services. So wie es aussieht wird das Sicherheitsleck seitens Yealink ab morgen 12.02.2020 geschlossen sein. Hier der Text dazu:

    【What have been updated?】
    To improve the overall quality and security of RPS service offering, Yealink has updated the RPS Service Policy as below:
    1. ...
    2. For existing phones which have been provisioned via RPS once, an additional two-factor device authentication is now required and implemented when these phones request for RPS service again. If the authentication fails, the phones will be blocked from accessing RPS service.

    【What may occur to your customers?】
    When you are doing a factory reset to reconfigure an existing phone via RPS service again, you may get a prompt on phone screen asking you to enter the last 5 digits of the Serial Number of this device. Please follow the instructions to enter the digits to finish the authentication. Otherwise, the device will not be able to connect to RPS.

    Gute Idee, mangelhafte Umsetzung:
    Die Seriennummern und MAC-Adressen der Geräte sind voneinander abhängig und werden einfach mit jedem produzierten Gerät inkrementiert :/
    Wird die MAC-Adresse um eins erhöht, erhöht sich die Seriennummer. Wenn man also ein paar Serien kennt, kann man das eine in das andere umrechnen.

  • Wo finde ich denn das RPS Admin Portal?

    https://dm.yealink.com/manager/login

    Wenn ihr dort keinen eigenen Zugang habt, gar nicht. Starface hat einen Zugang dazu und stellt die Telefone dort rein.

    Ich hab mir da auch mal einen Account einrichten lassen für Anlagen, die wir selbst außerhalb von Kundennetzen hosten. Hab die Mail also auch bekommen. Fand die Umsetzung bis jetzt eigentlich auch gut, bis ich den Kommentar von Fabian gesehen habe :P

    Viele Grüße,

    Andreas Stein
    IT Fabrik Systemhaus GmbH & Co. KG

    STARFACE Excellence PLUS Partner

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!