Sicherheit administrativer Dienste und Logins im Internet – Schwerpunkt SSH

Im Zuge unserer Sicherheitsüberprüfungen und Pentests auf Internet-erreichbare Systeme stolpern wir immer wieder über das Thema Sicherheit administrativer Dienste und die damit zusammenhängenden Risiken.

Ist ein System aus dem Internet erreichbar, dann kann jede mit dem Internet verbundene Person grundsätzlich darauf zugreifen – das sind mal sehr, sehr viele. Das bedeutet auch, dass wir eine hohe Eintrittswahrscheinlichkeit haben, dass jemand diesen Dienst finden und angreifen kann. Mit ein paar wenigen Schritten verbessern Sie die Sicherheit administrativer Dienste und deren Widerstandsfähigkeit gegenüber den permanenten Angriffen aus dem www.

Sicherheit administrativer Dienste – Passwortliste aus SSH-Brute-Force-Angriffen

In diesem Schritt ist es einem Angreifer übrigens vollkommen egal, wer das System betreibt oder was drauf ist: Ist SSH aus dem Internet erreichbar, dann wird es auch angegriffen. Täglich. In der Regel mehrfach!

Das gilt natürlich auch für über die Sicherheit administrativer Dienste und Protokolle wie SSH hinaus, z. B. auch für RDP, FTP, MySQL, … – Ende April haben wir nach nur wenigen Minuten sowohl für MySQL als auch RDP mehrere Zugriffsversuche festgestellt.

Ein Netzwerk- oder Schwachstellenscan kann beim Identifizieren solcher offener Dienste helfen. Hierzu reicht schon der geübte Umgang mit nmap – oder ein professioneller Security Partner.

Die andere Art von Angriffen – Ausnutzung bekannter Schwachstellen

Angriffe auf die Authentifizierung gibt es permanent. Aber nicht nur die – wie wirklich jeder spätestens seit der „ProxyLogon„-Lücke im Microsoft Exchange Server mitbekommen haben sollte. Werden Dienste mit bekannten Schwachstellen im Internet betrieben, dann werden sie auch angegriffen und erfolgreich kompromittiert. Oftmals sehr, sehr schnell.

Neue bekannte Schwachstellen gibt zehntausende pro Jahr. Jede davon kann potentiell ausgenutzt werden, um ein System anzugreifen, das nicht geupdated ist.

Sie patchen immer sofort und haben daher kein Problem? Na gut, treten wir noch etwas auf Microsoft und den Exchange Server ein:

  • 08.02.2021
    • Offizielle Vergabe der CVE-Nummern, also Bestätigung der Existenz der Schwachstelle (Microsoft kannte deren Existenz)
  • 02.03.2021
    • Notfallpatch durch Microsoft öffentlich bereitgestellt
  • 03.03.2021 – 13:01 Uhr
    • Erste Warnung des BSI vor aktiver Ausnutzung der Schwachstelle
  • 07.03.2021: Veröffentlichung erster lauffähiger Exploits auf Github, die es jedem Script-Kiddie ermöglichen, die Systeme anzugreifen
    • Hinweis: Microsoft (Besitzer von GitHub) hat mehrfach Exploit-Code von seiner Plattform entfernt und die Accounts der Forscher / Security Experten gesperrt. Es kann also durchaus schon früher lauffähige Exploits im Umlauf gegeben haben
  • 12.03.2021 – 15:46

Selbst wenn Sie also Ihre Exchange-Server direkt am Tag der Veröffentlichung gepatcht haben, kannten Angreifer bereits seit über vier Wochen einen Weg, den Server zu übernehmen.

Und – mal ganz ohne auf Microsoft einzuprügeln: So ist eben der normale Verlauf vieler Patches: Ein Angreifer oder Forscher findet die Schwachstelle, meldet sie – oder nutzt sie aus – der Hersteller erstellt ein Update und veröffentlicht dieses — irgendwann.

Juhu, ich bin drin – und jetzt?

Wer die „guten alten“ Zeiten noch kennt, in denen solche Angriffe von Script-Kiddies durchgeführt wurden, die anschließend Stolz in einem Forum verkündet haben, dass sie es geschafft haben, dem sei gesagt: die Zeiten sind vorbei.

Angriffe sind professioneller und zielgerichteter geworden. Wenn heute ein Angreifer erfolgreich in ein System eindringt, dann kann es auch eine Ransomware-Gruppe sein – die haben sich in der „grausigen“ neuen Zeit aktuell u.a. auf RDP-Ports eingeschossen

Der Schaden, wenn ein Angreifer erfolgreich ist kann also enorm sein: Von der Veröffentlichung der gestohlenen Daten über die weitere Kompromittierung des Firmennetzwerks bis hin zu Erpressungsversuchen.

Erhöhung der Sicherheit administrativer Dienste: Einschränkung der Zugriffsmöglichkeiten
Monitoring der Sicherheit administrativer Dienste mit Azure Log Analytics