Der von mir recht gerne gelesene Blog "BornCity" schrieb vorgestern:

(..) den in China beheimateten Hersteller Yealink (..) über die Deutsche Telekom z.a. als Yealink T54W SIP-Telefon vertrieben. Ein Blog-Leser hat mich nun darauf hingewiesen, dass die Geräte durchaus im Verdacht stehen, zur Spionage durch China missbraucht werden zu können und bat mich, das Thema mal im Blog aufzugreifen

und im folgenden Artikel wurde alles mögliche vermischt: Ein 2020 vermarkteter Sicherheits-Skandal (zu dem komme ich gleich), der Kontakt der Geräte zum Device Managment-Server des Herstellers,der Betrieb als Switch, die Möglichkeit, pcap-Dateien aufzuzeichnen uvam.

In der Folge wurden Borns Leser aktiv und schickten verschiedene teils widersprüchliche Aussagen, dass ihre Geräte sich nach China verbinden oder eben nicht. Und es liest sich so, als wären bestimmte Varianten betroffen, andere nicht, insbesondere hätten eigene Provider "spionage-freie Firmwareversionen". Insgesamt macht diese Zusammenfassung Angst vor Yealink-Telefonen. Und vieles davon halte ich für Unwissenheit und falsch.

Nun befasse ich mich beruflich seit 8 Jahren mit den Betrieb u.a. von Yealink-Telefonen an Cloud-Telefonanlagen, deren Autoprovisioning, aber habe auch für Geräte andere Hersteller wie z.B. unify Autoprovisioning-Server programmiert, d.h. ich versuche mal ein bisschen Substanz da reinzubringen.

Dass IP-Telefone nach Hause telefonieren, also einen Server des Herstellers kontaktieren, ist erstmal kein Skandal, sondern gewünschtes Verhalten.

Als Anbieter und Kunde willst Du ja Autoprovisioning haben, statt 30 verschiedene Einstellungen von Hand setzen zu müssen, letzteres ist fehleranfällig und supportintensiv, wenn der Kunde es selbst macht. Und wenn Du einen größeren Kunden hast, bei dem Du den Rollout vor Ort machst, gibt es auch deutlich schönere und erfüllerendere Tätigkeiten als auf 50 Geräten die gleichen Einstellungen von Hand setzen zu müssen.

Also: Man möchte, dass das Gerät von der Telefonanlage direkt mit der perfekten Konfiguration versorgt wird. Dazu muss das Gerät aber den Autoprov-Server der Telefonanlage (bei Yealink "RPS" - Remote provisiong service genannt) kontaktieren. Und dazu muss es nach dem Auspacken erstmal wissen, wie es den erreicht.

Genau dafür hat der liebe Gott DHCP erfunden. Das Gerät wird eingesteckt und der DHCP-Server verteilt nicht nur IP-Adresse, DNS usw., sondern er liefert auch direkt den Namen des zuständigen RPS-Servers mit. Nun klappt das in der Praxis aber nicht überall. Mindestens bei der Hälfte der Kunden würde man Fragezeichen im Gesichtsausdruck sehen, wenn es darum geht, auf dem DHCP-Server noch abweichende Flags zu setzen, das bekommen die nicht hin. (Ich habe sogar schon Kundennetze gehabt, in den der IT-Dienstleister "aus Sicherheitsgründen" gar keinen DHCP-Server betreibt, d.h. man sogar die IP-Adressen auf den Telefonen manuell eintragen musste). Oder es geht einfach nicht, weil es ein kleiner Kunde, ein Außenstandort oder vielleicht ein HomeOffice ist mit einem Speedport-FritzBox-UnityMediaSonstwas-Router, der das schlichtweg nicht kann.

Zweiter Ansatz, den z.B. Swyx auch bei seinen Unify-Tischtelefonen gewählt hat (und ich bei meinem Unify Firmware-/Quickconfig-Tool auch): Die Telefonanlage durchsucht das lokale Netzwerk nach provisionierungswilligen IP-Telefonen ab. Das klappt bei Swyx und den Unify-Telefonen gut, weil die Anlage da ja eigentlich (Swyx ist ja nie für Hosting geeignet gewesen) im gleichen Netzwerk steht wie die Telefone, oder im Hosting-Betrieb zwingend ein VPN braucht. Aber spätestens bei einer echten Cloud-Telefonanlage wird's schon komplizierter, womöglich noch, wenn die Arbeitsplätze und die Telefone beim Kunden nicht mal im gleichen IP-Netz hängen (womöglich ThinClients per RemoteDesktop) - richtig cool ist das auch nicht.

Viele, wahrscheinlich sogar die meisten Hersteller setzen optional auf den einfachsten Weg: Das Gerät meldet sich beim Hersteller. Der weiß irgendwie (meistens, konkret auch bei Yealink: Der Provider meldet über eine API die MAC-Adresse des Gerätes als "ist ein Kunde von mir") zu welchem Provider dieses Telefon gehört und an welchen RPS-Server es weitergeleitet werden soll. Und einen kurzen Moment später meldet sich das Telefon dann beim RPS-Server des Providers und bekommt seine Konfiguration.

Also: Es ist ein Feature, kein Indiz für ein Sicherheitsproblem.

Dazu müssen wir gedanklich einen Schritt zurück machen: Wie wird das Telefon denn dann konfiguriert?

Möglichkeit A: Der Kunde nutzt gar kein Autoprovisioning, sondern loggt sich im Webinterface seines Telefons ein und konfiguriert das Ding von Hand. Das betrifft weniger Büro-Telefonanlagen, sondern eher Privatkunden mit Einzelgeräten womöglich an der heimischen FritzBox, oder vielleicht auch mal ein DECT-Gerät, das womöglich von der Telefonanlage gar nicht per Autoprovisioning unterstützt wird. Ohne es zu wissen würde ich mal schätzen: Das Telefon verhält sich in dem Fall genauso wie bei Möglichkeit B und fragt trotzdem regelmäßig beim Hersteller nach, ob es was tun soll.

Möglichkeit B: Das Gerät wird einmalig an den RPS-Server des Providers geleitet, bekommt einmalig seine Konfiguration und läuft damit. In diesem Fall meldet es sich trotzdem regelmäßig (mein Eindruck ist alle 24h, aber ich habe es nicht analysiert; es betrifft nur unsere erste Generation AutoProvisioning) beim Yealink-Hersteller-Server. Für mich als Provider ist das erkennbar daran, dass ich im Yealink-DeviceManager (wo ich die Geräte meiner Kunden verwalten kann) sehe, wann ein Telefon zuletzt online war und von welcher IP-Adresse. Und ich könnte auch die Provisionierung zurücksetzen und neu durchführen lassen. Ersteres ist im Support bzw. auch bei der Fehlersuche bei Provisionierungsproblemen praktisch zu wissen, wenn ein Telefon eines Kunden nicht will, kann ich zumindest sehen, ob es Internet hat und nachverfolgen, wie weit es denn kommt. Und letzteres ist wichtig, wenn durch irgend eine Plattformänderung eine Konfiguraton zwingend neu ausgerollt werden müsste, kann ich das auch bei Geräten, die nur eine einmalige Konfiguration erfahren haben, erzwingen. Also auch hier: Es ist ein Feature.

Möglichkeit C: Das Gerät wird erstmalig an den RPS-Server des Providers geleitet, der liefert die Konfiguration aus und in der Konfiguration ist auch direkt ein AutoProvisioning-Server mit angegeben (wieder der des Providers). Dann meldet sich das Telefon regelmäßig (auch hier: M.E. alle 24h) beim Provider. Plus unregelmäßig auf Zuruf. Darüber realisieren wir dann die zweite Generation AutoProvisioning, der Kunde kann auch z.B. in seiner Telefonanlage die Tastenbelegung ändern, die Telefonanlage schickt dann eine SIP-Nachricht ans Endgerät (darüber kann sie das Telefon ja sowieso erreichen, sonst könnte man nicht telefonieren), nur eben statt einem INVITE für einen Anruf eine Auftragsnachricht, dass sich das Telefon neu provisionieren soll. Und das holt sich die neue Konfiguration ab, und die neue Tastenbelegung ist aktiv. In diesem Fall gibt es keine Notwendigkeit, dass das Telefon den Hersteller kontaktiviert (wozu? Es kennt ja seinen RPS-Server und solange der erreichbar ist, braucht es kein Fallback). Das wäre die Erklärung, warum einige BornCity-Leser eben keine Nachrichten nach China bemerken konnten - nicht weil der Anbieter eine "bereinigte" Firmware hat, sondern weil das Telefon komplett konfiguriert ist und keine Notwendigkeit besteht.

In dem Blog-Kommentaren wurde auch spekuliert, dass die Telekom ja vielleicht eine eigene Firmware hätte ohne Spionage drin. Das halte ich für Unsinn.

Den wahrscheinlicheren Grund, warum CloudPBX-Telefone nicht mehr nach Hause telefonieren, hatte ich im vorherigen Absatz schon erläutert. 

Dass die Telekom "eine eigene Firmware" hat, glaube ich alleine deshalb nicht, weil die Telekom ja auch "keine eigene Telefonanlage" hat. Sondern sie sind ein Gemischtwarenladen für verschiedenste Produkte verschienster Hersteller (als "Telekom Octopus Netphone" und als "DeutschlandLAN Cloud-Telefonanlage auf Basis Swyx" bzw. jetzt glaube ich unter anderen Namen gibt's da auch Swyx). Und wenn ein bestimmtes Produkt eine bestimmte eigene Firmware braucht, dann bekommt das bei der Telekom gekaufte Gerät auch diese eigene Firmware.

Zurück zu Yealink: Tatsächlich gibt es dort OEM-Versionen (für Swyx z.B. erkennbar an einem ".133"-Zusatz in der Versionsnummer. Warum sind die da? Weil der Hersteller enreach eigene Sonderwünsche für die Firmware hat - z.B. die Präsenzinformation rot/gelb/grün wird anders angesteuert als die meisten Mitbewerber es tun - und diese bezahlt (bzw. Abnahmemenge garantiert) und darum baut Yealink da irgendwas ein. Und weil das vom SIP-Standard zwar nicht abweicht, aber eben ungewöhnlich ist, könnte es mit nfon und STARFACE und wie sie sonst alle heißen kollidieren. Also kommen diese Sonderwünsche in die OEM-Version .133 rein und nur Swyx-Anwender haben die aktiviert, der Rest nicht. Ebenfalls kann diese OEM-Version für ein Provider-Locking benutzt werden (ohne spezielles Lizenzfile kann man diese OEM-Software nicht mehr gegen eine normale Firmware tauschen und das Telefon an keinem anderen Anbieter nutzen).

Natürlich könnte man in dieser OEM-Version auch das Autoprovisioning so umbauen, dass es keine Yealink-Server kontaktiert. Aber wozu? Zumindest vor ein paar Jahren, als es eine OEM-Firmware für Skype4Business gab, konnten wir über den Yealink-Support auch diesen Lizenz-Lock aufheben (und so aus einem S4B- ein SIP-Telefon machen), das würde dafür sprechen, dass auch die OEM-Versionen den Hersteller kontaktieren, um im Notfall einen Lizenz-Reset durchführen zu können.

Aber selbst wenn: Dann ginge es um Autoprovisioning, und das ist ja nicht böse. Böse ist ein möglicherweise heimlich in der Firmware untergebrachter Spyware-Schadcode, von dem nicht mal bei Yealink alle etwas wissen würden, d.h. der sehr tief versteckt sein müsste. Die OEM-Firmware stammt von wem? Von Yealink. Wenn da heimlich Schadcode drin versteckt ist, wer sollte sich die Mühe machen, den extra jedes Mal aus der OEM-Version wieder rauszunehmen? Und risikieren, dass sich jemand fragt, warum die Swyx-OEM-Version laut Dateigröße weniger Code enthält als die Standard-Firmware, die weniger kann? Zumal man bei der OEM-Version ja sogar vorhersagen kann, in welchem Zielmarkt die zum Einsatz kommen wird, das ist zum Spionieren doch viel besser?! Also entweder ich vertraue dem Hersteller, oder ich vertraue ihm nicht. Und wenn ich ihm nicht vertraue, dann ist auch die Idee, dass mir dieser Hersteller extra für mich eine saubere Firmware liefert, irgendwie absurd.

In dem Zusammenhang wurden auch andere mögliche Sicherheitsthemen von Yealink nochmal aufgewärmt. Die waren damals schon nicht gut.

Anfang 2020 hat Heise über eine Erkenntnis des Sicherheitsunternehmens VTRUST berichtet, der Artikel begann mit dem Teaser

Die Lücken klaffen im weltweit verwendeten Autoprovisionierungsdienst, der Telefone unkompliziert mit VoIP-Logins, Telefonbüchern und Anruferlisten versorgt.

Ich habe mich damals in das Thema eingelesen (betraf ja auch uns als Provider), habe mir von dem Heise-Redakteur im Prinzip bestätigen lassen, dass ich mit meiner Einschätzung richtig liege, aber für eine detaillierte Analyse hätte ich mich natürlich für viel Geld von VTRUST beraten lassen können. Ja, ne, ist klar.

Also: Was war damals los? Das Autoprovisioning erfolgt per http(s), die Erkennung, um was für ein Modell es sich handelt, über den User-Agent (da steht dann kein Browser drin, so wie es bei einem Webseiten-Aufruf wäre, sondern eben Yealink T42G irgendwas). Und das Telefon ruft eine URL auf, die an einer sauber dokumentierten Stelle (damit man als RPS-Entwickler sie auswerten kann) seine MAC-Adresse enthält, damit der Server weiß, wer da ist. 

Nun gibt es möglicherweise seitens Yealink keine Prüfung, ob das da wirklich ein Yealink-Telefon ist. Oder ob das ein Browser ist, der den richtigen Hostnamen (also sowas wie rps.yealink.com) gefolgt von einer plausibel klingenden MAC-Adresse ist. Und womöglich (ungetestet) hat Yealink dann gesagt "okay, Dein Gerät laut MAC-Adresse ist für den Provider XYZ registriert, bitte wende Dich per https an autoprovisioning.cloud-telefonanlage-irgendwas. Womöglich. Vielleicht haben die VTRUST-Hacker das auch gar nicht ausprobiert und sind einfach direkt zu einem (ihrem) Cloud-Telefonanlagen-Server gelaufen.

Und wenn da eine solche Anfrage ankommt, dann gibt man als Provider natürlich einfach so die Konfiguration (nebst Adressbüchern und vor allen Dingen SIP-Zugangsdaten) raus, oder etwa nicht? Mag sein, dass einige Anbieter das getan haben, ja. In unserem Produktdesign 2015 war dieser Angriffsvektor jedenfalls schon bekannt, darum lassen wir Autoprovisioning-Anfragen nur innerhalb eines kleinen Zeitfensters zu (entweder direkt nach Anlegen des Users. Oder nach Versandbestätigung der Hardware durch unseren Distri, wenn der Kunde über uns ein Yealink gekauft hat. Oder auf Knopfdruck des Users). Aber nicht einfach so, in der übrigen Zeit kommt ein solcher Angreifer nicht ans Ziel. Und das Swyx-eigene Autoprovisioning, was ein paar Jahre später dann kam, wurde mit einer zusätzlichen PIN als zweiten Faktor versehen, die der Kunde im Webinterface der Telefonanlage erfährt. Auch hier ist ein Zugriff durch dritte nicht möglich.

Es mag sein, dass andere Anbieter das anders handhaben. Das ist aber dann eine Sicherheitslücke in deren Implementierung, für die kann Yealink m.E. nichts.

Im BornCity-Beitrag wurde dann ebenfalls noch spekuliert, dass ein US-Senator erhebliche Bedenken habe. Naja, kein Wunder, er ist ja Amerikaner und dort sind solche Methoden ja nicht unbekannt. Und ja klar, was dis USA in Cisco-Routern machen können, können die Chinesen in Yealink-Telefonen genauso, denkbar ist alles. Aber außer, dass Yealink eben Chinesen sind gibt es keine weiteren Indizien.

Ach ja, und die Sache mit den Zertifikaten. Ja, es wäre deutlich sicherer, wenn Yealink in beide Richtungen SSL-Zertifikate einsetzen würde. Beim Abruf könnte ein RPS-Server so sicherstellen, dass das wirklcih ein Yealink-Telefon ist, dass da die Config haben will (und nicht ein Angreifer, der Zugangsdaten abgreifen will. Oder ein Man-in-the-middle-Zugriff, der die Konfiguration manipulieren will, bevor er sie ausliefert. Und umgekehrt könnte das Telefon prüfen, ob sein Gegenüber wirklich vertrauenswürdig ist bei der Konfiguration, die es da bekommt. Verzichtet Yealink drauf. Das ist unnötig und nicht gut. Machen aber (leider) alle anderen mir bekannten Hersteller auch, weil sie (leider) den Support-Aufwand scheuen, den man hat, wenn durch abgelaufene oder falsch ausgerollte Zertifikate irgendwann die Konfiguration nicht mehr will und die Telefonanlage stillsteht.

Zum Schluss ein Blick auf zwei andere Hersteller. WIr haben auch mal Autoprovisioning für Auerswald programmiert, die kochen mit dem gleichen Wasser wie Yealink auch. Auch hier muss man als Provider aufpassen, ob das Gerät wirklich vertrauenswürdig ist, auch hier gibt es keine Zertifikate, mit der Gerät oder Server die Identität des anderen prüfen können. Auch die Auerswald-Geräte haben einen Switch eingebaut und können vermutlich pcap-Dateien zu Diagnose-Zwecken mitschneiden (in einem bei Born zitierten Beitrag wurde daraus die Möglichkeit, "zu verfolgen, welche Webseiten die Benutzer besuchen"), und auch ein Auerswald-Gerät hat eine ausreichend mächtige CPU und ein leistungsstarkes Mikrofon, so dass man mit entsprechend modifizierter Firmware auch Raumüberwachung abbilden könnte. Wie übrigens alle anderen Hersteller auch. Und auch bei Auerswald setzt das eine modifizierte Firmware voraus (die man genauso leicht oder schwer ausgerollt bekommt, wie bei Yealink). Der einzige Unterschied wäre, dass man bei Yealink unterstellt, der Hersteller könnte das ab Werk schon eingebaut haben, weil ... es Chinesen sind.

Dann nehmen wir noch Unify, früher bekannt als SIemens, Sitz in München. Und an der Stelle mal etwas Meinung: Ich finde die alten Siemens- wie auch die aktuellen Unify-Telefone schöner als das, was Yeailnk baut. Die Bedienung ist für mich klarer (okay, ich komme ja auch noch aus www.hicom-faq.de-Zeiten damit klar).

Und die Dinger sind nachhaltiger. Sie halten einfach länger (grob geschätzt kommen auf 10 defekte Yealinks nicht mal ein defektes Unify). Es gibt sogar im Raum Köln einen sympathischen Händler, der die teilweise gebraucht aufbereitet. Die Geräte werden neuerdings bei Gigaset in Bocholt als Auftragsarbeit produziert - also Made in Germany. Der Berg an Plastik und Styropor, wenn man eine größer Installation mit Yealink hatte, und im Vergleich dazu das kleine Tütchen Plastik, was man nach einer gleich großen Installation mit Unify+Gigaset hat, ist schon ein krasser Unterschied. Also: Rein von der Modellpalette mein Favorit. Leider schlechteres Preis-/Leistungsverhältnis, und die meisten Kunden greifen dann, wenn wir ihnen beides anbieten, zum Chinesen..

Und trotzdem ich diese Geräte bevorzuge muss ich leider sagen, in Punkto Sicherheit rund um das Thema Autoprovisioning&Co, von dem wir hier reden, hat Yealink deutlich die Nase vorn:

• Zertifikate im Umgang zwischen DLS-Server (DLS, also Deployment-Service, ist bei Unify das gleiche, was Yealink RPS nennt) und Endgerät gibt es auch keine
• Einen zweiten Faktor gibt es nicht. Bei Yealink kann ich auf dem RPS-Server einfach eine klassische http-Auth-Passwortabfrage konfigurieren und der User wird am Endgerät nach Zugangsdaten fürs Autoprovisioning gefragt. Bei Unify geht das nicht, d.h. als Provider musst Du anders klären, dass Deine Zugangsdaten nicht durch https-Zugriffe-eines-angeblichen-Telefons abgegriffen werden. 
• Vergisst der Yealink-User (oder der Provider im Rahmen des Autoprovisionings) das admin-Passwort von "admin" auf etwas sicheres zu ändern, gibt es schon seit mehreren Jahren eine deutlich sichtbare Warnung im Display, dass das ein Sicherheitsrisiko ist. Bei unify gibt es keine Warnung, und zumindest im Swyx-eigenen DLS-Server wurde das auch jahrzehntelang nie geändert, d.h. erst seit kurzem kommt man nicht mehr per 123456 in jedes Tischtelefon einer SwyxWare-Installation rein.
• Und selbst wenn: Hast Du an Deinem Yealink das Admin-Passwort vergessen, hilft nur factory reset (oder, falls es per Autoprovisioning gesetzt wurde: Der Provider verrät es Dir oder setzt es neu). An einem Unify-Telefon kannst Du es - ohne die Konfiguration zu stören- mit meinem QuickConfig-Tool in wenigen Sekunden einfach neu setzen. 
• Yealink hat ein recht durchdachtes Konzept, was sind Änderungen, die per Autoprovisioning kommen, und was hat der User nachträglich geändert (und kann dann üblicherweise auch vom RPS-Server nicht überschrieben werden). Hier liegt die "Datenhoheit" beim Gerätenutzer, seine Wünsche haben Vorrang, da komme ich auch mittels kompromittiertem Autoprovisioning dann nicht dran bzw. nicht dran vorbei. Bei Unify ist es genau andersrum, der DLS-Server hat immer Vorrang und überschreibt alles, was der Kunde gesetzt hat. Und im Gegenteil, wenn ein Kunde etwas gesetzt hat, meldet das Telefon diese Änderung, z.B. Tastenbelegung auf Wunsch an den DLS-Server (d.h. es werden Daten "in die Cloud" übertragen), damit der DLS-Server sie speichern und bei der nächsten Konfiguration berücksichtigen kann (damit der User diese Tastenbelegung auch behält). Beide Ansätze kann ich nachvollziehen, aber der von Yealink ist eher in Richtung "Datenhoheit liegt beim User".

Ich habe mich bei beiden Herstellern intensiv mit deren DLS- bzw. RPS-Logik befasst. Und wäre ich ein gemeiner Hacker, der mit Kapuzenpulli im Rechenzentrum an einem Schreibtisch sitzt, dann könnte ich folgendes tun:

• ich bringe einen Mitarbeiter einer anzugreifenden Firma dazu, eine von mir mit ein bisschen JavaScript versehen Webseite aufzurufen
• damit scanne ich (analog meines QuickConfig-Tools) sein Netzwerk nach Unify-Telefonen ab
• wenn ich eins finde, das nach Konferenzraum klingt, ändere ich ggf. (wenn nicht schon vorhanden) die Firmware auf SIP
• konfiguriere danach einen SIP-Account eines SIP-Servers von mir, der alles aufzeichnet
• wenn es ein aufwendigeres Display hat, z.B. ein altes OpenStage 60 ist, lade ich als Screensaver-Foto noch ein Bild eines OpenStage im Ruhezustand hoch 
• aktivere "auto-answer" und aktiviere den Screensaver nach 5 Sekunden

Und schon habe ich im Konferenzraum ein Gerät stehen, das ich jederzeit von meinem SIP-Server aus anrufen kann (schicke einen Header mit, dass das Gerät direkt rangeht) und was nach 5 Sekunden wieder im Display einen Ruhezustand suggeriert und verschweigt, dass es gerade auf Freisprechen mit-telefoniert. 

Bei Yealink wüsste ich im Moment nicht, wie ich von außen einfach so, ohne Kenntnis des Admin-Passwortes und ohne selbst ein Gerät im Netzwerk des Kunden zu haben, einen ähnlichen Angriffsvektor habe.

Aber ja, eine entsprechend mächtige Organisation, die sich den Aufwand macht einer eigenen Firmware und diese durch Unterwandern des Herstellers ausrollt, würde es auch mit Yealink hinbekommen....

Am Ende des Tages sind auf dem BornCity-Blog leider nur haltlose Spekulationen einiger Leser zu finden. Und die auch nur ausgelöst, weil Yealink ein chinesischer Hersteller ist. Was ja auch ok ist (der Autor schreibt ja selbst, er kann es nicht beurteilen). Aber man gewinnt trotzdem den Eindruck, dass was dran sein könnte.

Ja klar, kann auch sein, keine Frage. Yealink kann jederzeit ein Autoprovisioning-Request umleiten (ob freiwillig oder unfreiwillig durch ein paar Hacker) und dann bekommt das Telefon eine andere Konfiguration, womöglich lädt es eine kompromittierte Firmware runter. Aber das gilt nahezu identisch für fast alle anderen IP-Telefone auch. Und für viele andere IT-Spielzeuge auch.