We are living in the Roaring New Twenties. Software is eating the world, just like Marc Andreessen predicted, and every company has become a software company, following the forecast of Forbes Magazine. This new world of software runs natively in the Cloud, or better yet, in its modern embodiment, Kubernetes.

Companies of all sizes are moving towards the Cloud, deploying applications faster through DevOps, opening new markets, and exploring new possibilities. In the most innovative industries, OpenShift has been chosen as the de facto Kubernetes-based platform for business applications. Thanks to its integration of CI/CD processes, user management, enterprise integrations, and developer-friendly features, OpenShift supports the new wave of financial innovation. Couple that with the trust of big names such as Red Hat and IBM, plus guaranteed support and updates, no wonder it has become the new standard.

But how can you differentiate your offering from your competition in such a Zeitgeist market, or, as Kim and Mauborgne named it in 2004, a “Red Ocean” of competitors and industries? Simply put, through innovation and high value products. You must relentlessly focus on your core competencies more than ever, and in software terms, that means listening to your customers, and keeping an eye on your own capacity to deliver new features.

Businesses find it hard, however, to break new ground when their development teams are busy operating -or fixing- infrastructure issues every day; backups, updates, monitoring; all essential tasks, but taking a toll on your team morale and your finances.

VSHN, the DevOps company, helps smart businesses by taking care of the maintenance of their OpenShift platforms, so that they can build the next big idea. Just like Acrevis did; with 8.4 billion CHF assets under management and 146 full-time employees, Acrevis provides IT services to other fintech players, and VSHN makes sure that it all just works, 24/7, 365 days a year.

Every company has different needs; some must operate within the Swiss borders, for legal or other reasons, and might thus be tempted to choose to run their own expensive on-premises infrastructure. This was the case of Neon (the first independent bank account app of Switzerland, where everything is done comfortably from your smartphone.) Nowadays, not only does VSHN take care of Neon’s OpenShift clusters, managed by a Swiss team certified by FINMA, ISO, and ISAE; we also make sure that their operations and data stay safely in Switzerland.

Last but not least, we have helped companies migrate their applications to OpenShift; and we can do that for you too. But do not take our word for it; see what we did for esurance or CreditGate24, just to name a few of the success stories experienced by our customers.

Do not let the Zeitgeist of the Cloud drown your business in a „Red Ocean“ of competition and operations. Get in touch with VSHN today and let us help you shape the future of your business.

Manchmal stösst man bei der Arbeit als Site Reliability Engineer auf Situationen, die so nicht sein sollten. So war es auch Mitte Januar 2018, als ich für ein privates Projekt an einer Icinga2-Installation arbeitete. Ich versuchte über die Konsole eine interne Funktion von einem CheckCommand-Objekt aus der Icinga2-Skriptsprache aufzurufen:

get_check_command("dummy").execute(null, null, null, false)

Daraufhin stürzte der Icinga2-Daemon wegen der Dereferenzierung eines NULL-Zeigers ab. Nach kurzer Lektüre des Codes war klar, dass nur wenige per Skript erreichbare Funktionen ihre Parameter mit der nötigen Sorgfalt prüfen.

Mein Interesse war geweckt und so suchte ich nach einer Möglichkeit, diesen Absturz über die Icinga-API herbeizuführen. Ohne „console“-Berechtigung war dies jedoch nicht direkt möglich.

Allerdings fand ich dann eine Reihe von anderen Problemen, die allesamt übers Netzwerk von extern ausnutzbar sind und als „Denial of Service“ klassifiziert werden können. Beispielsweise wurden bei mehreren API-Endpunkten die Parameter ohne vorgängige Kontrolle dereferenziert. Folgender Code benötigt keine Authentifizierung und führt bei allen Icinga2-Versionen vor 2.8.2 zu einem Absturz:

msg=$(jq --null-input --compact-output --raw-output '{
  "id": "foo",
  "jsonrpc": "2.0",
  "method": "event::Heartbeat",
  "params": null
}') && \
{ sleep 1; echo "${#msg}:${msg},"; sleep 3; } | \
openssl s_client -connect 192.0.2.1:5665

Weitere Beispiele dieser Art sind in meinem technischen Bericht zu finden. Einige davon benötigen ein Client-Zertifikat, andere setzen eine bestimmte Konstellation der Master und Clients voraus.

Daneben fanden sich mehrere Szenarien, in denen auf dem Server unbegrenzt Ressourcen, vor allem Arbeitsspeicher, konsumiert werden. Mit diesem Python-Code beispielsweise wird eine grosse Anzahl TCP-Verbindungen geöffnet, die dann unbenutzt liegen bleiben und wovon jede im Icinga2-Daemon einen Thread mit dazugehörigem Stack belegt:

import resource
import socket
import time
resource.setrlimit(resource.RLIMIT_NOFILE, (131072, 131072))
conn = []
while True:
    try:
        conn.append(socket.create_connection(('192.0.2.1', 5665)))
    except BaseException as err:
        print(err)
        break
print(len(conn))
while True:
    time.sleep(1)

Je nach verfügbaren Ressourcen auf dem Server wird der Icinga2-Daemon schon nach kurzer Zeit vom OOM-Killer im Linux-Kernel beendet.

Beim Lesen des Codes stellte sich auch heraus, dass Passwörter mit std::string::operator== verglichen werden. Diese Funktion, wie auch strcmp, bricht den Vergleich ab, sobald ein Unterschied vorliegt. Ein Angreifer kann die Zeitunterschiede messen und damit eine Seitenkanalattacke durchführen.

Auf meiner privaten Webseite habe ich einen technischen Bericht mit weiteren Details zu den von mir gefundenen Sicherheitsproblemen in Icinga 2.8.1 und älter veröffentlicht. Version 2.8.2 von Icinga behebt diese und weitere. VSHN hat Icinga2 auf sämtlichen relevanten Kundensystemen bereits aktualisiert.