Ingenieurssoftware-Archäologie

Ingenieurssoftware hat oft eine kleine aber feine Zielgruppe – ein Grüppchen, das globale Softwarekonzerne nicht unbedingt im Visier haben. Dementsprechend atmet die Benutzeroberfläche oft nolstalgisch-spartanischen Charme.

Aber auch in den Tiefen solcher Software gibt es aufsehenerregende Funde aus dem Software-Paläozoikum – genau das richtige für das Elkement, das diese Bugs versteckten Features unerbittlich erschnüffelt. Von einem Paradebeispiel aus der täglichen Schnüffelpraxis soll diese Geschichte handeln! Wie der prähistorische Schnüffler aus Ice Age ist das Elkement beharrlich … und wird aber am Ende ausgetrickst.

Was man hätte sehen sollen (in jener Software): Ein Bild der Bedienelemente einer Regelung und darüber schwebende Zahlen. Mit Rumspielen an den abgebildeten Knöpfchen hätte man das echte Gerät simulieren können.

Was man sah: Eine Fehlermeldung in einem mutmaßlich fernöstlichen Zeichensatz.

Natürlich fragt der geübte Sniffer als Erstes Google Translate um Hilfe:

Die [XY]-Gerätedatei kann nicht gelesen werden.

… und es gibt tatsächlich eine Datei xydevice.xls … die sich aber mit Excel lesen lässt (?!) … also zumindest lassen sich die überwiegend fernöstlichen Zeichen in den Tabellen darin betrachten.

Nächster Schritt: Wahlloses Durchtesten der üblichen Fallstricke für Software aus vergangenen Epochen? 32bit versus 64bit? Administrator-Rechte? Dateiberechtigungen? Muss eine alte Windows-7-Maschine wiederbelebt werden? … und tatsächlich: Ein einziges Mal sieht der erschöpfte Schnüffler ganz kurz die Animation der XY-Regelung: Beim ersten Test auf einer paläozoischen Maschine (Windows 7 und 32bit). Leider ist der Test nicht reproduzierbar, also wird unerschrocken weitergeforscht.

Ein professionelles Schnüffelwerkzeug – Microsoft Sysinternals Process Monitor – zeigt, dass die Software erfolgreich auf die rätselhafte Datei zugreift:

Process Monitor: Prüfung Zugriff auf xls-Datei durch Anwendung

Kurz vor dem Zugriff arbeitet sich die Software durch Datenbanktreiber (‚JET‘) für Office-Dateien – die letzte davon ist msexcl40.dll – damit kann eine XLS-Datei wie eine Datenbank abgefragt werden.

Aber in dieser Schnüffelspur sieht man keine Fehlermeldung: Die xls-Datei wird geschlossen, bevor das Popupfenster mit Fehlermeldung erscheint … also ist die Anwendung halbwegs kontrolliert mit dem Fehler fertig geworden und hat ihn richtig ‚gehandled‘.

Das Elkement bzw. die Datenkrake haben langjährige einschlägige Erfahrung im wilden Basteln mit Konstrukten aus Excel- / Access- und Textdateien, die zu fragilen Datenbanken vereinigt werden. D.h. im Programmierer aus der fernen Zeitzone erkannte das Elkement eine verwandte Seele. Es versuchte, sich in diesem Lao Tse der Office-Programmierung hineinzufühlen. Beim einzig erfolgreichen Start des Programms waren einige XML-Dateien erzeugt worden. Soweit erahnbar durch Zeichenvergleich, wurden aus der xls-‚Datenbank‘ Einträge zu einem Gerät bestimmten Typs gelesen und in die XML-Datei geschrieben.

Aber was ging schief? Der Schnüffler der nächsten Tiefe wird gestartet – der Windows Debugger WinDbg (Teil der Debugging tools for Windows). Mit Reverse-Engineering-Halbwissen stolpert das Elkement zur nächsten unhandled oder handled exception – und wieder fällt msexec40.dll unangenehm auf:

Output Windows Debugger - Fehler bei Datenbankzugriff - msexec40.dll

Und da war sie endlich – die google-bare Fehlermeldung im Microsoft-O-Ton:

Unexpected error from external database driver (1).

So richtig optimistisch machte dieser eher generisch und schlicht gehaltene Text ja nicht. Aber man glaubt es kaum – es gab tatsächlich einen relativ neuen Microsoft-Artikel, der exakt diesen Fehler im genau passenden Kontext auflistet. In einem Überblick über  Betriebssystem-Updates von Herbst 2017 wird über ein Problem mit älteren JET-Datenbanktreibern für xls-Dateien brichtet – über einen neuer Fehler, der genau seit diesem Windows-Updates auftritt:

Microsoft-Artikel - Problem mit JET-Treiber / xls-Dateien nach Update

Damit kann endlich eine plausible Erklärung für den einzig erfolgreichen Test formuliert werden: Die Software wurde auf diesem länger nicht gestarteten Windows-7-Computer getestet – exakt als die Updates der letzten Monate noch nicht installiert worden waren, inklusive dem in diesem Artikel erwähnten Update.

Auch der dezente Hinweis von Microsoft, doch einen neueren Datenbanktreiber zu verwenden – neuer als Stand Office 2007 – passt dazu: Die ausführbaren Dateien der prähistorischen Softwaren waren alle ca. 10 Jahre alt.

Wie der possierlich-zappelige Schnüffler aus Ice Age wurde das Elkement damit mit einem Dilemma konfroniert und ausgetrickst: Um die Sicherheit nicht zu gefährden [Bitte Buzz Words passend einsetzen: Cyber Security – Internet of Things] wurde das unerbittliche Windows Update nicht mehr deinstalliert. Damit bleibt nur zu hoffen, dass entweder Lao Tse den Datenbanktreiber austauscht oder dass Microsoft, wie im Artikel angekündigt, das prähistorische Feature wieder aktiviert.

Unfreundliche Anwendungen mit schlechtem Benehmen

(… oder: Endlich wieder ein Beitrag aus der Akte-X-Serie…)

Das Elkement ist eine typische IT-Security-Abteilung und versucht daher den produktiven Ingenieursabteilungen die tägliche Arbeit so mühsam wie möglich zu machen.

So wurde auf dem Chefingenieurs-Notebook das neueste Windows-10-Feature gleich ausprobiert – Controlled Folder Access. Windows 10 Defender wacht über Zugriffe auf definierte Ordner und wehrt Angriffe von unfreundlichen Applikationen ab.

Und als ebensolche wurden gleich Winsol (und dann auch TAPPS) eingestuft:

Fügt man Winsol.exe in der Windows Defender Konfiguration zur Liste der erlaubten Anwendungen hinzu (Allow an App), ist der Spuk vorbei.

Beim Testen dieser Funktionen wurde das Elkement auf folgendes fundamentale Rätsel der Winsol-Konfiguration aufmerksam: Wo werden die Winsol-Daten eigentlich per Default gespeichert? …. ein jahrelang vernachlässigtes Forschungsgebiet! Die Siedler hatten ja in jeder Winsol-Installation immer gleich ihren eigenen speziellen Logfile-Ordner eingestellt – dort wo z.B. die hungrige Datenkrake auf die Logfiles wartet.

In einer frischen Winsol-Installation begegnet einem aber dieses Mysterium:

Aus Winsol heraus betrachtet – beim Versuch den Standardordner zu ändern, sieht man die neuesten Logfiles in C:\Program Files\Technische Alternative\Winsol\LogX (rechts im Bild). Direkt im Explorer (links im Bild) sucht man den LogX-Ordner aber vergeblich, ebenso wie die Infosol-Ordner mit den Kundendaten:

Bevor sich das Elkement mit so etwas theoretisch beschäftt, wird einmal geschnüffelt mit Microsoft Sysinternals Process Monitor.

Aha! Winsol greift in Wirklichkeit auf einen Unterordner VirtualStore im Benutzerprofil zu – hier gibt es eine ‚Umleitung‘ (REPARSE):

Die Logfiles verstecken sich somit hier:

C:\Users\[Benutzer]\AppData\Local\VirtualStore\Program Files\Technische Alternative\Winsol

Dieser VirtualStore ist ein seit Vista genutztes Sicherheits-Features, wenn Anwendungen etwas zu ‚anmaßend‘ sind. Hier ein Beispiel:

…  in most cases when a developer tells his program to save data in the Program Files folder, for example, program settings, he has completely forgotten that program settings should be a per-user thing! … In other words, a well-behaved application should instead save its settings in the
C:\Users\<User Name>\AppData\Local\<Manufacturer>\<Product>\<Product Version>

Ever since Windows Vista, applications that are not running with raised privileges that try to write to the Program Files (or Program Files (x86)) folder will in fact write to the VirtualStore folder, unknowingly.

Es gibt es aber auch einige offizielle Winsol-Einstellungen pro Benutzer im Ordner:

C:\Users\[Benutzer]\AppData\Roaming\Technische Alternative\Winsol

Hier wird z.B. das Cookie für die Anmeldung am Webportal abgelegt – aber eben nicht die Logfiles.

Zusammengefasst: Möchte man jetzt die aktuelle Winsol-Installation auf einen anderen PC übertragen oder lokal den Ordner ändern – und in mehrfacher Hinsicht ’sicher‘ konfigurieren, also sicher vor Hackern und vor allem für sich selbst auffindbar, geht der unerschrockene Monitoring-Bastler so vor:

  • Winsol wird auf dem Ziel-PC neu installiert.
  • In den Grundeinstellungen wählt man einen Ordner außerhalb von ‚Programme‘ – am besten dort, wo man auch andere Projektdateien speichert – also in einem Ordner für den eine regelmäßige Sicherung erfolgt (Z.B.: Cloud und externe Festplatte)
  • In diesen neuen Ordner werden die Dateien aus dem alten Winsol-Ordner kopiert, also alle ‚eigenen‘ Logdateien, exportierte CSV-Dateien und ggf. auch die Unterordner anderer Kunden im Ordner Infosol. (Das gilt nur dann uneingeschränkt, wenn auch die gleiche Winsol-Version verwendet wird – vor ca. 1 Jahr gab es ja eine subtile mehrstufige ‚Migration‘ bedingt durch Regler- und Software-Updates.)
  • Um sich das einmalige Anmelden am Portal zu sparen, kann auch der Inhalt von C:\Users\[Benutzer]\AppData\Roaming\Technische Alternative\Winsol kopiert werden.
  • In Controlled Folder Access in Windows 10 muss Winsol.exe in die Liste der erlaubten Anwendungen eingetragen werden (oder der Logfile-Ordner ausgenommen – sicherer ist, nur Winsol zu erlauben).

_______________

Nachtrag 2018-01-31: Die Tests wurden mit der Winsol-Version 2.07 durchgeführt, kurz bevor die Version 2.08 zur Verfügung gestellt wurde. 2.07 war auf diesem PC ein Upgrade einer früheren Version.

Installiert man Winsol 2.08 neu (auf Windows 10), dann wird mittlerweile als Standardordner ein Unterordner im Profil vorgeschlagen – gutes Benehmen wie von Microsoft empfohlen 😉

C:\Users\[Username]\Documents\Technische Alternative\Winsol

Gönnen wir dem CMI sein eigenes Netz!

oder:

Wie Irgendwessen Problem gelöst wurde, weil das elkement gerne schnüffelt, was die ‚Dinge‘ so machen im Internet of Things.

Irgendwer stand vor einer besonderen Herausforderung: Der Chefingenieur und Regler-Freak hatte das ideale Plätzchen gefunden: Genügend Platz und Ruhe, um UVR16x2, CMI & Co für seine Projekte aufbauen, verkabeln und testen zu können. Fast ideal, wenn man es genau nahm. Denn die Siedler hatten diesem Plätzchen kein LAN gegönnt. Das CMI  – das Control and Monitoring Interface, also das ‚Ethernet-Gateway‘ des Reglers – konnte nicht angeschlossen werden. Damit wäre Irgendwer zurück in die Steinzeit des SD-Karten-Hin-und-Hertragens geworfen worden.

Aber ‚glücklicherweise‘ legten gerade einige ganz besonders fiese Kameras und Videorekorder das halbe Internet lahm – und das elkement erinnerte sich dadurch an eine bereits einmal hier publizierte Anleitung zum Thema: Wie kann man als normaler Windows-Benutzer ohne Hackererfahrung herausfinden, welche Botschaften diese (bösen?) Dinge in die Welt senden und empfangen?

Hier wurde ein von Profis oft belächeltes Feature von Windows genutzt – die so genannte Internetverbindungsfreigabe: Ein normaler Windows-PC kann damit in einen Router verwandelt werden: Der PC verbindet sich wie immer per WLAN ins lokale Siedlernetzwerk – und damit ins Internet. Das ‚Ding‘ wird mit den LAN-Anschluss des PC verbunden und kann die ‚freigebene‘ Internetverbindung nutzen. Nachdem der PC jetzt höchspersönlich alle Netzwerkpakete des Dinges weiterreicht, kann der investigative Benutzer diese auch mit Sniffer-Software auf diesem PC untersuchen.

Aber eigentlich kann man diese Funktion ja einfach so verwenden, wie sie vielleicht gedacht war: Einem WLAN-unfähigen Ding wird eine Brücke ins Internet gebaut.

Aus Klimaschutzgründen wurde natürlich ein ausrangiertes Testnotebook verwendet, dem so ein zweites Leben als wichtiger Router ermöglicht wurde.

Die folgende Grafik zeigt die ‚Netzwerkarchitektur‘:

Netzwerk zum Testen eines CMI mit Regler UVR16x2 in seinem eigenen Subnetz

Der Ethernetanschluss des Laptop-Routers wird von Windows mit der IP-Adresse 192.168.137.1 konfiguriert, sobald die Internetfreigabe aktiviert wurde. Dieser Computer wird zum DHCP-Server und weist dem dem ‚Ding‘ eine dynamische IP-Adresse aus demselben Netzwerk zu, z.B. 192.168.137.2. Der WLAN-Adapter erhält eine Adresse aus dem sonst verwendeten ‚Office‘-Netzwerk (oft: 192.168.0.x)

Für Details zu den Einstellungen am PC siehe den früheren Artikel über das Internet der Dinge. Unter Windows 10 muss/kann jetzt auch die Netzwerkverbindung nicht mehr ausgewählt werden, auf der das Ding sitzt. Kleiner Tipp, bestätigt durch die bewährte Methode ‚Googlen in Foren‘: Wenn unter Windows 10 die Internetverbindungsfreigabe nach einem Neustart nicht mehr funktioniert, muss sie nochmals in den Eigenschaften des WLAN-Adapters deaktiviert und wieder aktiviert werden.

Wie früher schon berichtet wurde, kann so eine Kaskade von Netzwerken auch sinnvoll sein, um ein sensibles Ding (wie den Logger BL-NET) vor einem besonders gesprächigen Ding (IP-TV) zu schützen.

Irgendwer konnte somit wahlweise über das Router-Notebook lokal auf das CMI zugreifen oder über das Internet, also sozusagen bei der Türe raus und beim Fenster wieder rein. Da man vom lokalen ‚Office‘-Netzwerk gar nicht direkt lokal auf das CMI kommt (sondern nur über die ‚Cloud‘), ist das auch halbwegs realistischer Test der späteren Fernwartung über das Internet.

Die Reglerprogrammierung ging damit eigentlich fast schneller als das Aufräumen des Spielplatzes Arbeitsplatzes danach:

irgendein-stilles-plaetzchen-unaufgeraeumt

Das Internet der Dinge

Die Siedler betonen gerne, dass sie bodenständige Wissenshandwerker sind, die bezüglich visionären Phrasen eine gesunde Skepsis an den Tag legen.

Gewissen Trends können sie sich dennoch nicht verschließen.

Wer würde nicht wollen, dass der Kühlschrank automatisch Pizza nachbestellt oder PV-Module stolz ihren täglichen Ertrag twittern? All das fällt unter den Begriff Internet der Dinge. Diese Dinge sind oft auf abenteuerliche Weise – gewollt oder ungewollt – mit dem Internet verbunden.

Im Sinne einer realistischen Abschätzung von Sicherheitsrisiko zu Nutzen ist praktische Forschungsarbeit nötig. So führen die Siedler eine minuziöse Untersuchung sämtlicher netzwerkfähiger Dinge in ihrer Siedlerhütte durch. Welches Ding kommuniziert ungefragt mit dem Dem Internet? Und welche Siedlergeheimnisse werden dabei ausgeplaudert?

Entgegen den Klischées in Hacker-Filmen ist es gar nicht so einfach, den Netzwerkverkehr mitzuschnüffeln. Das war einmal, als unsere Netzwerkverkabelung noch mit dem Antennenkabel verwechselt werden konnte:

10base2 t-pieceWehmütig bereuen die Siedler auch, ihren Hub aus dem letzten Jahrtausend entsorgt zu haben. Wie beim Koaxialkabel würde jedes angeschlossene Ding alle von allen anderen Dingen versendeten Netzwerkpakete sehen können.

Heute sind auch im billigsten Internet-Router schon Switches eingebaut. Das Möchtegern-Hacker-Notebook kann dadurch nur noch jene Pakete lesen, die für seine Hardwareadresse bestimmt sind.

Davon lässt sich das Elkement nicht aufhalten – und es hat ein Ziel: Der breiten Öffentlichkeit, also auch dem typischen Windows-Benutzer, zu ermöglichen, die Kommunikation seiner Dinge mitzuverfolgen.

Die Lösung besteht darin, das Ding zu zwingen, mit Dem Internet nur über das Hacker-Notebook zu kommunizieren. Das Notebook wird zum Router; das Ding befindet sich also hinter einer Kaskade von zwei Routern: 1) dem Hacker-Notebook und 2) dem eigentlichen Internet-Router.

Dafür verwenden wir ein wenig bekanntes und wahrscheinlich in Expertenkreisen belächeltes Feature: Die Internetverbindungsfreigabe in Windows.

Ein Router hat mehr als eine Netzwerkkarte und verbindet mindestens zwei (adressmäßig unterschiedliche) Netzwerke.

Ein typisches Laptop hat diese beiden Netzwerkadapter!

  1. WLAN – zur Verbindung mit dem Internet-/WLAN-Router
  2. LAN – eine RJ45-Buchse für ein Ethernetkabel.

(2) wird nun verwendet, um das Ding anzuschließen, bzw. genauer gesagt, ein kleines privates Netzwerk aufzubauen, das nur das Ding enthält. Dafür wird ein ausgekreuztes Kabel verwendet.

Zusätzlich muss eine Sniffer-Software installiert werden, wie z.B. das frei verfügbare  Wireshark.

Ziel ist der folgende Aufbau – in der Darstellung werden der Standard-IP-Adressbereich der Verbindungsfreigabe verwendet (192.168.137.x) und 192.168.0.x als typisches internes Netz:

|     Ding    |       |      Laptop-Router      |      |Internet-Router
|     LAN     |-cross-|     LAN     |    WLAN   |-WLAN-|Internes LAN
|192.168.137.2|       |192.168.137.1|192.168.0.2|      |192.168.0.1

Konfiguration:

  • Eigenschaften des WLAN-Adapters suchen, in Windows 7 unter:
    Systemsteuerung
    –Netzwerk und Internet
    —-Netzwerkstatus und -aufgaben
    ——Adaptereinstellungen ändern
  • In den Eigenschaften des WLAN-Adapters auf Freigabe klicken und anhaken der Option: Anderen Benutzern im Netzwerk gestatten die Internetverbindung dieses Computers zu verwenden.
  • In einem Dropdown-Menü werden alle anderen Adapter außer dem zu teilenden angezeigt – hier wird die Lokale Internetverbindung als privates Netzwerk ausgewählt:

  • Der LAN-Anschluss des Dinges wird über das Crossover-Kabel mit der LAN-Buchse des Laptops verbunden.
  • Wenn das Gerät DHCP verwendet, erhält es automatisch eine IP-Adress aus dem Bereich 192.168.137.x. Wenn nicht, muss eine statische Adresse mit x ungleich 1 vergeben werden. Das Router-Notebook erhält die Adresse 192.168.137.1 und ist  DHCP-Server, DNS-Server, und Default Gateway.
  • Wireshark starten, klick auf Capture, Interfaces…, Auswahl des Adapters mit der Adresse 192.168.137.1 … und … Start!

Ein harmloses Praxisbeispiel – der Blu-Ray-Player der Siedler:

Das Ding erhält eine Adresse über DHCP – nur das letzte Paket (‚acknowledge‘) ist hier gezeigt – und versucht dann die MAC-(Hardware-)Adresse für den Router-Computer 192.168.137.1 zu finden – ein DELL-Laptop. Benötigt wird nämlich ein DNS-Server, um einen offenbar hart-kodierten Namen aufzulösen: liveupdate.blurayplayer.samsung.com.

Gut, dass die Kommunikation nicht verschlüsselt ist – sonst könnten wir nicht so einfach mithören.

Mit der Wireshark-Option Follow TCP stream sieht man noch besser, was jetzt passiert:

Der Player ruft die Seite liveupdate.jsp über HTTP auf, schickt die Typenbezeichnung, eine Versionsnummer und den Standort ‚EU‘. Samsung sieht diese Anfrage von der nicht wirklich anonymen IP-Adresse der Siedler in einem kleinen mitteleuropäischen Land kommend.

Samsung antwortet mit [NO UPDATE] und einem Cookie, das bereits vor 3,5 Jahren abgelaufen ist.

Und die Moral aus dieser Geschichte? Nicht, dass es überraschend wäre, dass Geräte versuchen, sich automatisch Updates von einem Server im Internet zu holen. Computer machen das seit ‚ewigen Zeiten‘ – allerdings mit dem ‚feinen‘ Unterschied, dass man hier das Updateverhalten als Besitzer 1) prinzipiell kontrollieren könnte und 2) auch das Mitverfolgen sehr viel einfacher wäre.

Unser Vorschlag für Was gibt es Neues: Das Ding der Woche an seinem Internetraffic zu erkennen!

Liebe Heizungsbastler und Messtechnikfreaks…

Auch ich habe schon viel Blödsinn gemacht

… um einen vom Elkement geschätzten Professor zu zitieren.

Der ‚Blödsinn‘ bezog sich in jenem Fall auf solche Erdwärmebohrungen und was man daraus lernen kann – ohne sich jetzt über die Betroffenen lustig zu machen:

Staufen, Risse nach Geothermiebohrung

Staufen, Risse nach Bohrungen für Erdwärmesonden, eines der historischen Gebäude wurde um 45cm gehoben. (Wikimedia, Benutzer Ekem)

In diesem Sinne und ohne IT-Fuzzi-ist-ja-so-gescheit-und-macht-sich-lustig-Allüren:

Auch das Elkement  hat schon auf dubiose Links geklickt und sich den einen oder anderen Virus eingefangen. Jeder ist in einem schwachen Moment auch nur ein Benutzer.

Trotzdem, liebe Heizungsbesitzer:

!!! BITTE !!! stellt Eure Heizungssteuerung nicht ungeschützt ins Internet!

Mittlerweile hat fast jedes konfigurierbare Gerät irgendeine Art von Weboberfläche. Hat man die Verfügungsgewalt über den eigenen Internet-Router kann diese auch „im Internet freigegeben“ werden durch Portweiterleitung. Man sollte hier aber wissen, was man tut. Bedenklich stimmen uns Diskussionen in Foren, die mit Hilferufen gestartet werden wie DNS, VPN, Ports, TCP/IP sagt mir jetzt Null – kann mir jemand erklären, wie ich meine Heizung über das Internet freigeben kann?

Irgendwessen Regelung kann über die Webanwendung des BL-NET bedient werden. So sollte es aussehen, wenn sie von extern erreichbar ist:

BL-NET Webanwendung, Passwörter wurden gesetzt.

BL-NET Webanwendung. Die Meldung zeigt, dass Passwörter gesetzt wurden.

So sollte es nicht aussehen:

BL-NET Webanwendung. Passwörter nicht gesetzt.

BL-NET Webanwendung. Hier wurden keine Passwörter gesetzt.

Beides sind Screenshots von Anlagen, die mittels (einer sehr simplen Variante von) Google-Hacking gefunden wurden. Im zweiten Fall würden sich nicht nur Regelungsparameter verstellen lassen, sondern ein „Scherzbold“ könnte auch Passwörter erstmals setzen und den legitimen Benutzer damit aus seiner eigenen Anlage aussperren. Der Benutzer kann dann nur die Steuerung auf Werkseinstellungen zurücksetzen und das hoffentlich vorhandene Backup einspielen.

Leider können wir die Anlagenbesitzer nicht warnen, da die Computernamen keine direktem Rückschlüsse auf den Besitzer zulassen (zumindest nicht ohne weitere Hacker-Aktvititäten). Viele Benutzer verwenden Dienste wie dynDNS oder NoIP um ihre Geräte trotz dynamischer IP-Adresse von außen erreichen zu können.

Vielleicht ist nicht klar, dass auch ein dynamisch vergebener Name à la 47-11-08-15.dyn.provider.komischername.com auffindbar und evtl. Google-bar ist. Ob man unter dieser Adresse dann wirklich etwas Angreifbares findet, hängt von der Lebensdauer des Namens ab.

Systematischer lassen sich Anlagensteuerungen mit der Gerätesuchmaschine Shodan aufspüren:

BL-NET-Geräte, die über das Internet zugänglich sind

BL-NET-Geräte, die über das Internet zugänglich sind – Ergebnis einer Suche mit Shodan. Ob Passwörter gesetzt wurden oder nicht, würde ein Zugriffstest zeigen.

Mit Shodan wurden unter anderem Verkehrsampeln, Webkameras und medizinische Überwachungsgeräte gefunden.

Selbst wenn Passwörter gesetzt wurden, können Schwachstellen in den verwendeten Webapplikationen dazu führen, dass dieser Schutz umgangen werden kann. Diese mittlerweile behobene Lücke führte zu einer Ausgabe der Passwörter von Heizungssteuerungen direkt im Browser.

Von der BL-NET-Applikation können wir in diesem Zusammenhang nur Positives berichten – sie widersetzt sich allen Versuchen, mögliche Lücken ausnutzen.

Alternativ zu dieser direkten Freigabe der Ports von außen gehen Gerätehersteller dazu über, den Kunden ein Webportal anzubieten. Hier müssen keine Ports an der eigenen Firewall freigegeben werden. Ähnlich zu Fernwartungsdiensten wie Teamviewer baut das Gerät immer selbst eine Verbindung von innen nach außen auf und verhält sich damit firewalltechnisch wie jeder andere „surfende“ Computer im Netzwerk. Das externe Webportal „vermittelt“ dann nur eine Verbindung von außen nach innen über diesen bereits geöffneten Kanal.

Was kann man mit vertretbarem Aufwand als Benutzer tun?

  • Immer Passwörter setzen, auch wenn ein Gerät „vorerst eh nur intern“ verwendet wird – oder Standard-Passwörter (1234, admin) ändern.
  • Firmware von Geräten mit Weboberfläche (Internetrouter, Steuerung) aktuell halten – damit ist die Chance geringer, dass bekannte Schwachstellen ausgenutzt werden können.
  • Suche der eigenen Geräte mit den oben erwähnten Methoden. In Shodan kann  net: verwendet werden.
  • Durchführen eines kleinen eigenen Penetration Tests mittels Tools, die Schwachstellen in Webservern aufspüren (nur im eigenen Netz und nur gegen eigene Geräte!!)
  • Im Zweifelsfall: Angriffsfläche minimieren und Nutzen/Risiko der Internetfreigaben abwägen.

____________________

Weiterführende Links:

UDP Hole Punching – Kommunikation mit einem Gerät hinter einer Firewall (NAT): http://resources.infosecinstitute.com/udp-hole-punching/

Google Hacking im Detail: https://www.blackhat.com/presentations/bh-europe-05/BH_EU_05-Long.pdf