B4ckdoor-owned-you

Das Grundrauschen des Internets ist normalerweise kein Grund zur Sorge - sofern man sich mit den Hintergründen befasst. Betreibt man über das Internet erreichbare Systeme, erfordert das ständige Wachsamkeit. Ein treffendes Beispiel hierfür ist eines meiner Erlebnisse aus der Vergangenheit.

Das Daily Business

Wirf man einen flüchtigen Blick auf die bereits existierenden Beiträge auf diesem Blog, kann man erahnen, dass ich mich neben einigen anderen Themen auch mit Servern beschäftige. Das Planen und anschließende Verwirklichen einer IT-Infrastruktur bereitet mir große Freude.

Unabhängig davon, ob es sich um ein privates Projekt oder eines für meinen Arbeitgeber handelt - meist spielen Server eine zentrale Rolle. Natürlich bin ich kein ausgebildeter IT-Systemadministrator, würde allerdings von mir behaupten, die ein oder andere wertvolle Erfahrung gemacht zu haben. Eine dieser Erfahrungen schreibe ich in Form dieses Beitrags nieder und hoffe damit, einen kleinen Denkanstoß geben zu können.

Die Ausgangslage

Aktuell arbeite ich mit einer ganzen Reihe geschätzter Kollegen und Kommilitonen an einigen Projekten. Da der Vorfall über den ich hier berichte zwei unterschiedliche aber dennoch verwandte Systeme betraf, folgt hier eine kurze Auflistung der Fakten:

Projekt A

Infrastruktur betrieben auf der Open Telekom Cloud (OTC)
Komponente: 1 Elastic Cloud Server (ECS-Instanz) mit einer Linux-Distribution
Software-Stack: Docker, Nginx, NodeJS, MongoDB
Eine Subdomain einer Root-Domain zeigt auf IPv4 der ECS-Instanz, Bsp.: projekt-a.example.com

Projekt B

Infrastruktur betrieben auf der Open Telekom Cloud (OTC)
Komponente: 1 Elastic Cloud Server (ECS-Instanz) mit einer Linux-Distribution
Software-Stack: Docker, Nginx, NodeJS, MongoDB
Eine Subdomain einer Root-Domain zeigt auf IPv4 der ECS-Instanz, Bsp.: projekt-b.example.com

Was ist passiert?

An einem Montagnachmittag vor drei Wochen hatte ich auf Bitten des Teams von Projekt B damit begonnen, die Infrastruktur für die zu entwickelnde Software einzurichten. Keine Rocket Science. Eine neue ECS-Instanz war rasch erstellt und eingerichtet. Um den Verwaltungsaufwand zu minimieren noch schnell (eine maßlose Untertreibung) die CI/CD-Pipeline basierend auf GitLab.com eingerichtet und fertig. Sobald die Entwickler neue Funktionen erstellt hatten, konnten Sie durch einen Merge den Deployment-Prozess auslösen. Der Code wurde - vereinfacht gesagt - automatisch auf den Server der OTC ausgerollt und die Änderungen konnten live eingesehen werden.

Wie aus der obigen Auflistung schon ersichtlich wurde, nutzen wir als Webserver einen Nginx der gleichzeitig als Reverse Proxy agiert und die Anfragen einer bestimmten Domain an die hinter ihm liegende NodeJS-App weiterleitet. Diese greift bei Bedarf auf die MongoDB-Datenbank zu. Diese drei Dienste/Programme laufen in eigenen Docker-Containern. Gibt es also ein Problem, kann ich mir die Logs jedes Containers anzeigen lassen. Gesagt getan. Natürlich trat ein Problem auf und ich durchstöberte die Logs der einzelnen Services. Erfahrene Systemadministratoren und IT-Professionals werden bei den nun folgenden Schilderungen sicher schmunzeln.

Mein "Nervositätsgrad" beginn aus heiterem Himmel anzusteigen, als ich in den Logs des Nginx-Webservers diesen Eintrag sah:

webapp    | 77.81.xxx.xxx - - [08/Jun/2020:18:57:31 +0000] "POST /cgi-bin/ViewLog.asp HTTP/1.1" 301 169 "-" "B4ckdoor-owned-you" "-"
webapp    | 77.81.xxx.xxx - - [08/Jun/2020:18:57:31 +0000] "7%3b%23&remoteSubmit=Save" 400 157 "-" "-" "-"

Analysieren wir kurz, was passiert ist: Ein Gerät mit der IP-Adresse 77.81.xxx.xxx hat versucht, über einen HTTP POST-Request auf die Datei "ViewLog.asp" die Inhalte selbiger zu verändern. Aus irgendeinem Grund wurde der User Agent auf den Wert "B4ckdoor-owned-you" geändert. Normalerweise gibt diese Angabe einige Informationen über das anfragende Gerät und den verwendeten Browser weiter. So sieht der User Agent meines Chrome-Browsers der auf meinem Windows 10 Rechner läuft wie folgt aus:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36

Wer auch immer diese Anfrage geschickt hat, wollte also eine ganz bestimmte Datei auf dem Server verändern und diese Dreistigkeit noch nicht einmal verbergen.

Dieser Logeintrag war zu allem Überfluss immer und immer wieder in den Nginx-Logs zu sehen. Der einzige Unterschied war der Ursprung der Anfrage - die IP-Adresse. Also nur Spam? Nicht ganz. Zugegeben war ich etwas nervös und habe schnell die Logs des Webservers von Projekt A (also der anderen ECS-Instanz) überprüft. Auch hier waren die selben Einträge zu finden. Okay. Anscheinend wird fieberhaft versucht, den Inhalt einer auf beiden Servern nicht existierenden Datei zu verändern. Merkwürdig.
Da beide Webserver diese Anfragen mit dem HTTP-Fehlercode 400 (Bad Request) abgelehnt haben, bestand also kein Grund zur Sorge. Dachte ich.

Beide Server laufen in der Open Telekom Cloud und hatten jeweils eine IPv4-Adresse die dicht beieinander lagen. Um mich abzusichern, habe ich direkt nach dem Sichten der Logs einen meiner Kollegen angeschrieben, von dem ich wusste, dass er ebenfalls einige Server in der Open Telekom Cloud betreibt. Allerdings wurde keine seiner Maschinen derart "angegriffen". Also doch ein zielgerichteter Angriff auf mich?

Die Rückmeldung meines Kollegen hat meinen Nervositätsgrad auf einen unangenehmen Stand angehoben. Da Vorsicht ja bekanntlich besser als Nachsicht ist, exportierten der angesprochene Kollege und ich also auf beiden Servern der Projekte A und B die Logs aller wichtigen Dienste (wie Nginx, NodeJS-App und MongoDB). Unmittelbar danach haben wir beide Maschinen durch die Firewall der OTC abgeschottet und gänzlich vom Netz genommen. Mittlerweile war es schon spät und ich informierte beide Teams über den Vorfall.

Rat einholen

Es war der nächste Morgen und mein Handy zeigte viele neuen Nachrichten in Abwesenheit an. Nachdem ich dann endlich im Büro angekommen war und alle offenen Fragen beantwortet hatte, schaute ich mir die Logs erneut an. Ein Zugriff auf die NodeJS-Anwendung (geschweige denn die MongoDB) fand nicht statt. Nur auf den Webserver wurde in der oben beschriebenen Art zugegriffen.

Mein Arbeitgeber hat - wie wohl jede größere Firma - eine ganze Reihe von fachkundigen Kollegen, die sich tagein tagaus mit IT-Security beschäftigen. Dort konnte sich jeder im Notfall professionelle Unterstützung einholen. Eine E-Mail mit den Logs im Anhang war rasch erstellt und abgeschickt. Nach kurzer Zeit rief mich einer der Kollegen an und klärte mich etwas auf.

Laut ihm ist dieser Angriff bereits seit längerem bekannt. Genauer handelte es sich bei den anfragenden/angreifenden Geräten um Router der Firma ZyXEL. Hier in Deutschland sind die Router der Firma nicht wirklich weit verbreitet. Ganz im Gegensatz zu den Niederlanden. Dort gibt es einige Internet Service Provider (wie bei uns die Telekom, Vodafone, und Co.), die ihren Kunden ZyXEL-Router für den Heimgebrauch zur Verfügung stellen.

Ein Wurm hatte anscheinend einige dieser Router infiziert und versucht, sich weiter zu verbreiten. Die Intention eines Wurm ist es hierbei, sich vorerst (im Gegensatz zu beispielsweise Ransomeware) eher unbemerkt zu verbreiten. Es sollen also möglichst viele Systeme infiziert werden, bevor fortgefahren wird. Bereits infizierte Systeme dienen dabei als Verbreiter. Es entsteht eine Art Kettenreaktion.

Ein Wurm der explizit nach einer Schwachstelle in ZyXEL-Routern gesucht hat, sorgte also für diese unerwünschten Zugriffe. Noch vor diesem Tag fand ich diese Rahmeninformationen mit einer raschen Websuche heraus - war mir aber nicht ganz sicher, ob ich richtig lag.
Eine genauere Beschreibung der ausgenutzten Schwachstelle gibt es hier.

Warum diese beiden Server?

Der Wurm hatte bereits eine ganze Reihe von Routern infiziert. Diese suchten ihrerseits nun weiter nach verwundbaren Geräten im Netz. Interessanterweise wurden lediglich die beiden Server der Projekte A und B angegriffen - nicht aber die Infrastruktur hinter der eingangs erwähnten Root-Domain. Daraus lässt sich schlussfolgern, dass die Domains in diesem Fall keine Rolle gespielt haben.

Nachdem der Wurm also einen Router erfolgreich infizieren konnte und nun dieser versucht weitere Systeme zu infizieren, kommt es zu einem Abprüfen des IP-Adressraums der jeweiligen Router. Jeder Infizierte prüft folglich die Systeme in "seiner Nähe" auf diese Schwachstelle. Ist eine solche vorhanden, kann sie ausgenutzt werden. Laut dem Kollegen der IT-Security liegt der IPv4-Adressraum eines niederländischen Internet Service Providers (80.126.0.0 - 80.126.255.255) in unmittelbarer Nähe zu dem Adressraum der Open Telekom Cloud. Wie es der Zufall wollte, wurde ich damit ungewollt zum Ziel dieses automatisierten Angriffs.

Da ich keine ZyXEL-Router betrieben habe, ist dieser Angriff also im Endeffekt relativ unbedenklich und wurde auch von besagtem Kollegen als "Grundrauschen" betitelt.

Lessons Learned

Eine Gefahr zu unterschätzen ist meist deutlich gefährlicher, als sie zu überschätzen. Ein eigener Server ist schnell und einfach aufgesetzt und eingerichtet. Nur sollte man am Ende des Tages nicht nur die Wünsche der "netten" Nutzer sondern auch die Vorhaben der Nutzer mit weniger guten Absichten beachten.

Einen Server kann man sich wie das eigene Haus oder die eigene Wohnung vorstellen:
Wenn ich gehe, schließe ich nicht nur die Tür als offensichtlichen Eingang, sondern auch die Fenster. Da meine Adresse meist kein Geheimnis ist, muss ich damit rechnen, hin und wieder Besuch (habe er nun gute oder böse Absichten) zu erhalten. Trotz alledem fühle ich mich wohl, weil ich der Besitzer bin und die Hoheit über mein Haus bzw. meine Wohnung habe. Damit dieser Umstand nicht gefährdet wird, halte ich einfache Regeln und Verhaltensweisen ein und sorge damit für eine höhere Sicherheit.

Meinen Server schotte ich deshalb mit einer Firewall vor der Außenwelt ab. Sofern ich Dienste wie einen Webserver von außerhalb erreichbar mache, muss ich auch für seine Sicherheit Sorge tragen.

Bevor man nun ganz wild mit der Suche nach Server-Security-Anleitungen beginnt, hilft ein regelmäßiger Blick mit einem wachsamen Auge in die Logdateien der einzelnen Services weiter. Ich spreche aus Erfahrung.