Wird mit SSO alles besser oder alles schlimmer, oder was?

Single Sign-on und die Sicherheit
Keine Kommentare

Single Sign-on (kurz SSO), das bedeutet, man muss sich nur einmal einloggen und schon ist man überall drin. Das ist praktisch. Aber auch gefährlich. Denn das SSO erspart Ihnen das Merken von Zugangsdaten für etliche Dienste – und einem Angreifer das Knacken dieser vielen Zugangsdaten. Der muss auch nur den SSO-Zugang knacken und kommt in Ihrem Namen überall rein.

Ganz allgemein bedeutet Single Sign-on, dass sich der Benutzer bei einem Dienst authentifiziert, irgendeine Form von Token erhält und danach mit diesem Token im Rahmen seiner Berechtigungen ohne erneute Authentifizierung auch auf andere Dienste zugreifen darf. Angeblich wird SSO manchmal mit verzeichnisbasierten Authentifizierungssystemen verwechselt, bei denen der Benutzer sich bei jedem Dienst manuell anmeldet, dabei aber immer die gleichen, in einem zentralen Verzeichnis gespeicherten Zugangsdaten verwendet. Dabei ist der Unterschied eigentlich leicht zu erkennen und zu merken:

  • Single Sign-on = Einmal anmelden, danach erfolgt die weitere Authentifizierung/Autorisierung im Hintergrund
  • Verzeichnisbasierte Authentifizierung = Einmal anmelden, und mit den gleichen Daten woanders anmelden, und dann noch mal, und …

Eigentlich sollte man meinen, dass man das doch kaum verwechseln kann, oder?

Mögliche Angriffe aufs SSO

Auch bei den möglichen Angriffen unterscheiden sich die beiden Ansätze. Beim reinen Ausspähen von Zugangsdaten gibt es keinen Unterschied: Wer die Zugangsdaten kennt, kann sich damit sowohl beim SSO als auch bei der verzeichnisbasierten Authentifizierung genauso wie der Benutzer anmelden. Anders sieht es aus, wenn der Angreifer sich über andere Wege Zugriff verschafft:

  • Ein Angreifer, der sich erfolgreich Zugriff auf das SSO verschafft, kann danach auf alle damit verbundenen Dienste zugreifen, das SSO-System stellt ihm bereitwillig das nötige Token aus, da er ja als authentifiziert gilt.
  • Bei der verzeichnisbasierten Authentifizierung hat der Angreifer nur Zugriff auf den angegriffenen Dienst. Für den Zugriff auf weitere Dienste muss er deren Authentifizierung separat brechen. Außer, wenn er nach dem ersten Angriff die Zugangsdaten ausspähen kann, mit denen er sich dann wieder überall anmelden kann.
  • Beim SSO ist zusätzlich das Token ein weiteres Angriffsziel, da damit der Zugriff auf die anderen Dienste möglich ist. Gelangt der Angreifer an ein gültiges Token und gibt es keine weiteren Schutzmaßnahmen, kann er sich damit als der betreffende Benutzer ausgeben.

SSO-Lösungen im Überblick

Kommen wir zu einigen Möglichkeiten für das SSO. Einige habe ich bereits in vorherigen Artikeln behandelt, auch wenn dabei das Buzzword „Single Sign-on“ nicht gefallen ist. Dazu gehört z. B. Kerberos, unter Windows in der Kombination mit Active Directory.

Kerberos

Angriffe auf Active Directory habe ich zuletzt im Windows Developer 6.2018 vorgestellt [1], und darin kamen auch Angriffe auf Kerberos vor. Konkret ging es damals zunächst um Angriffe auf die Delegation von Kerberos. Als Delegation wird der Fall bezeichnet, dass ein Benutzer auf ein Frontend zugreift, das dann in seinem Namen mit einem Kerberos-Ticket auf ein Backend zugreift. Das Frontend agiert dabei gegenüber dem Backend als der betreffende Benutzer.

Delegation-Accounts lassen sich leicht entdecken und können danach vom Angreifer missbraucht werden, um sich höhere Benutzerrechte zu verschaffen (indem der Angreifer sich als beliebiger Benutzer ausgibt und danach die diesem zugänglichen Dienste missbraucht), um Zugangsdaten auszuspähen, Daten auszuspähen oder Code auszuführen. Details dazu können Sie in [1] nachlesen.

Ein weiteres Problem sind die Service Principal Names (SPN, Dienstprinzipalnamen), an denen Kerberos erkennt, welcher Security Principal für die Ausführung einer Anwendung oder eines Diensts verantwortlich ist. Diese werden nicht überprüft, lediglich aufgerufene Dienste prüfen, ob ein Service Ticket mit dem Secret Key des zuständigen SPN verschlüsselt wurde. Der Secret Key ist der Passwort-Hash des Service-Accounts, und Tickets mit dem gleichen Secret Key sind untereinander austauschbar. SPNs, die zum gleichen Account gehören, sind also generell austauschbar, außerdem die Tickets aller Accounts mit dem gleichen Passwort-Hash.

Windows Authentication/NTLM Authentication/…

Bleiben wir bei Windows. Nachdem Sie sich in Ihren Windows-Rechner eingeloggt haben, erlaubt Ihnen die Windows Authentication automatisch den authentifizierten Zugriff auf andere Dienste, so z. B. über den Webbrowser auf Webanwendungen im lokalen Netz.

Für die Windows Authentication gibt es noch etliche weitere Bezeichnungen, z. B. NTLM Authentication (da für die Authentifizierung die Sicherheitsprotokolle des NT LAN Managers (NTLM) verwendet werden), „Integrated Windows Authentication“ (IWA) oder Windows Integrated Authentication, Domain Authentication, …. Es sieht fast so aus, als hätte Microsoft es anfangs versäumt, einen eindeutigen Namen festzulegen, sodass jeder Unternehmenszweig seine eigene lokale Bezeichnung verwendet.

NTLM ist für das sog. NTLM Relaying anfällig, das zum oben schon erwähnten Missbrauch von Authentifizierungstokens gehört. Wobei bei NTLM kein Token zum Einsatz kommt, sondern ein Challenge-Response-Verfahren, das von Windows automatisch durchgeführt wird, wenn sich der Benutzer mit einem die NTLM-Authentifizierung nutzenden Dienst verbindet.

NTML Relaying: Grundlagen

Die NTLM Authentifizierung besteht vereinfacht aus vier Schritten (Abb. 1):

  1. Authentifizierungs-Request des Clients an den Server: Zuerst werden das Protokoll und die vom Client unterstützten Features ausgehandelt. Der Client sendet einen Authentifizierungs-Request an den Server, der u. a. die akzeptierte NTLM-Version enthält.
  2. Server-Challenge-Nachricht des Servers an den Client: Im nächsten Schritt antwortet der Server auf den Request und nennt u. a. die akzeptierte NTML-Version und die gewünschten Features sowie seinen Challenge-Wert.
  3. Authentifizierungs-Response des Clients an den Server: Der Client berechnet aus dem Challenge-Wert des Servers und dem Passwort des Benutzers den Response-Wert und schickt ihn an den Server. Außerdem gibt er dabei an, zu welchem Benutzernamen und zu welcher Domain das für die Berechnung der Response verwendete Passwort gehört.
  4. Prüfen der Response: Der Server berechnet seinerseits den Response-Wert und vergleicht sein Ergebnis mit dem vom Client gelieferten Wert. Stimmen beide Werte überein, ist der Benutzer authentifiziert.
Abb. 1: Die NTLM-Authentifizierung allgemein

Abb. 1: Die NTLM-Authentifizierung allgemein

Der NTLM-Relay-Angriff

Beim Relay-Angriff bringt der Angreifer den Rechner seines Opfers dazu, sich mit seinem Rechner zu verbinden und baut gleichzeitig eine Verbindung zu einem Dienst seiner Wahl auf. Dann reicht er die Challenge- und Response-Daten durch und kann sich so gegenüber dem Dienst als der entsprechende Benutzer authentifizieren (Abb. 2). Der Angreifer (bzw. genauer: sein Rechner) muss sich für diese Angriffe im gleichen lokalen Netz wie das Opfer befinden. Dabei muss er aber nicht physisch anwesend sein, der Angriff kann z. B. auch von einen durch Schadsoftware kompromittierter Clientrechner in diesem Netz ausgehen.

Die NTLM-Authentifizierung ist in andere Protokolle gekapselt, die Nachrichten sind aber unabhängig vom äußeren Protokoll immer die gleichen. Dadurch können die NTLM-Nachrichten in anderen Protokollen verwendet werden. Wenn sich der Client z. B. über HTTP authentifiziert, werden die NTLM-Authentifizierungsnachrichten im Authorization-Header übertragen. Ein Angreifer kann diese Nachrichten aber aus dem HTTP-Header in jedes andere NTLM unterstützende Protokoll (außer HTTP(S), z. B. SMB, LDAP, IMAP, SMTP, POP3 und MSSQL) kopieren. Wenn die NTLM-Authentifizierung z. B. an den SMB-Server weitergeleitet wird, kann der Angreifer darauf einen Service starten und darüber seinen eigenen Code ausführen. Bei der Weiterleitung an LDAP können Objekte im Verzeichnis modifiziert werden, um dem Angreifer höhere Privilegien zu verschaffen etc.

In Abbildung 2 gibt sich der Angreifer als Webserver aus und baut seinerseits eine Verbindung zu einem SMB-Server auf. Die über HTTP erhaltenen NTML-Nachrichten verpackt er in SMB-Nachrichten und umgekehrt.

Abb. 2: NTML-Relay-Angriff

Abb. 2: NTML-Relay-Angriff

Die Verbindung zum Angreifer

Was jetzt noch fehlt, ist die Antwort auf die Frage, wieso sich der Rechner des Opfers mit dem des Angreifers verbinden und dabei die NTML-Authentifizierung nutzen soll.

Eine aktuelle Antwort haben z. B. Jianing Wang und Junyu Zhou auf der Hack in the Box Dubai im November 2018 geliefert: Weil sich der Angreifer beispielsweise als WPAD-Server (Web Proxy Auto-Discovery, informiert den Webbrowser über den zuständigen Web-Proxy) ausgibt und sich selbst über eine gefälschte Proxy-Konfigurationsdatei zum zuständigen Web-Proxy deklariert. Danach leitet der Browser des Opfers alle Requests über den Rechner des Angreifers, der dann in die HTTP-Responses beliebige Inhalte einfügen kann. In diesem Fall natürlich solche, die zu einer NTLM-Authentifizierung des Opfers beim Angreifer führen. Jianing Wang und Junyu Zhou haben in ihrem Vortrag verschiedene Angriffe über NTLM Relaying vorgestellt, darunter auch einige neue.

Ein aktueller Angriff auf und über Exchange

Ende Januar 2019 wurde ein interessanter Angriff auf die NTLM-Authentifizierung vorgestellt. Dirk-Jan Mollema hat einen NTLM-Relaying-Angriff mit einem Angriff auf Exchange kombiniert, um sich nach dem Erlangen der Admin-Rechte auf einem Exchange-Server Domain-Rechte zu verschaffen. Dabei kommt ihm zu Gute, dass Exchange-Server per Default (zu) hohe Rechte in der Active Directory Domain haben, was man auch schon als Schwachstelle ansehen könnte.

Konkret besteht das Problem darin, dass die Gruppe „Exchange Windows Permissions“ WriteDacl-Zugriff auf das Domain-Objekt im Active Directory hat. Das erlaubt es jedem Mitglied dieser Gruppe, die Domain-Privilegien zu ändern, wozu auch die Berechtigung zur Ausführung von DCSync-Operationen gehört. Dieses Recht wiederum erlaubt es, Synchronisationsoperationen durchzuführen, die normalerweise vom Domain Controller zur Replikation verwendet werden. Und das erlaubt es einem Angreifer, alle gehashten Benutzerpasswörter im Active Directory zu synchronisieren. Nachdem er die Hash-Werte kennt, kann er damit für jeden beliebigen Benutzer ein Kerberos „Golden Ticket“ erzeugen und sich damit als der betreffende Benutzer ausgeben oder sich als beliebiger Benutzer bei jedem Dienst anmelden, der die NTLM-Authentifizierung oder Kerberos verwendet.

Angriff 1: NTLM Relaying

Das NTLM Relaying funktioniert in diesem Fall genauso wie oben beschrieben. Konkret muss der Angreifer in diesem Fall einen Exchange-Server dazu bringen, sich mit der NTLM-Authentifizierung bei ihm zu authentifizieren. Und dafür ist der zweite verwendete Angriff zuständig.

Angriff 2: Exchange zur Authentifizierung bewegen

Dieser Angriff basiert auf einem Mitte Dezember 2018 von der Zero Day Initiative (ZDI) vorgestellten Exploit für die Schwachstelle CVE-2018-8604 im Exchange-Server. Es ist möglich, Exchange über das PushSubscription-Feature dazu zu bewegen, sich über HTTP gegenüber einem beliebigen URL zu authentifizieren. Der von der ZDI entwickelte Angriff besteht darin, dass ein authentifizierter Benutzer der Outlook-Web-App (OWA) die NTLM-Authentifizierung zurück zum Exchange Web Services API (EWS API) leitet (was als Reflektionsangriff/Reflection Attack bezeichnet wird). Das API läuft mit NT-AUTHORITY\SYSTEM-Rechten, mit denen der Angreifer sich dann als beliebiger Benutzer ausgeben und z. B. auf dessen E-Mails zugreifen kann.

Single Sign-on kann also im Fall eines Angriffs außer der eigentlichen Bedeutung auch noch eine andere haben: Einmal als (bösartiger) Benutzer eingeloggt, und schon hat der Zugriff auf die Mailkonten aller anderer Benutzer.

1. Angriff + 2. Angriff = 3. Angriff

Dirk-Jan Mollema kombiniert den ZDI Exploit mit den hohen Defaultrechten von Exchange, um sich über einen NTLM-Relay-Angriff diese hohen Rechte zu verschaffen und sich danach selbst die DCSync-Rechte zu gewähren. Damit kann er sich dann wie oben schon erwähnt die Passwort-Hashes aller Active-Directory-Benutzer beschaffen und sich danach als jeder dieser Benutzer ausgeben. Abbildung 3 zeigt den Angriff im Überblick. Er besteht aus fünf Schritten:

    1. Der PushSubscription-EWS-Aufruf startet den NTML-Relaying-Angriff.
    2. Der Exchange-Server baut eine HTTP-Verbindung mit NTLM-Authentifizierung zum Rechner des Angreifers auf.
    3. Der Angreifer leitet die NTML-Authentifizierung des Exchange-Servers an den Domain-Controller weiter. Der bestätigt zum Schluss dem Angreifer die erfolgreiche Authentifizierung.
    4. Der Angreifer modifiziert mit den Rechten des Exchange-Server-Accounts die Domain-Privilegien, um sich das Recht für die Ausführung von DCSync zu verschaffen.
    5. Er führt den DCSync-Angriff durch und synchronisiert die Passwort-Hashes. Nachdem er die hat, kann er sich damit als beliebiger Benutzer ausgeben.
Abb. 3: Der Angriff von Dirk-Jan Mollema

Abb. 3: Der Angriff von Dirk-Jan Mollema

Security Assertion Markup Language

Kommen wir zur nächsten SSO-Lösung, der auf Basis der Security Assertion Markup Language SAML. Dabei handelt es sich um ein XML-Framework zum Austausch von Authentifizierungs- und Autorisierungsinformationen zwischen einem Client, einem SAML-Identity-Provider und einem SAML-Service-Provider.

Wenn der Benutzer mit seinem Browser eine durch einen SAML-Service-Provider geschützte Webressource aufruft, sendet der Service-Provider über den Browser einen Authentifizierungs-Request an den SAML-Identity-Provider. Hat sich der Benutzer noch nicht beim Identity-Provider angemeldet, muss er das nun tun. Nach der erfolgreichen Authentifizierung des Benutzers sendet der Identity-Provider dem Service-Provider die passenden Credentials des Benutzers, der diesem daraufhin den Zugriff erlaubt (oder ggf. auch verweigert, wenn keine oder falsche Credentials geliefert werden). Nach der ersten Anmeldung beim Identity-Provider erfolgt die Übertragung der Credentials automatisch.

Kelby Ludwig hat auf der Black Hat USA 2018 und der OWASP AppSec 2018 USA von ihm entdeckte Schwachstellen in verschiedenen SAML-Implementierungen präsentiert. Um Manipulationen an den ausgetauschten XML-Nachrichten zu erkennen, werden diese signiert. Ein vereinfachtes, signiertes SAML-Dokument kann wie in Listing 1 aussehen.

<Response Destination="serviceprovider.com">
  <Assertion ID="thing_to_sign">
    <Subject>
      <NameID>kelbyludwig</NameID>
    </Subject>
    <AttributeStatement>
      <Attribute Name="role">
        <AttributeValue>admins</AttributeValue>
      </Attribute>
    </AttributeStatement>
  </Assertion>
  <Signature Id="signature_id">
    <SignedInfo>
      <CanonicalizationMethod Alg="xml-c14n11"/>
      <SignatureMethod Algorithm="rsa-sha256"/>
      <Reference URI="thing_to_sign">
        <Transforms>
          <Transform Algorithm="xmldsig#base64"/>
        </Transforms>
        <DigestMethod Algorithm="sha1"/>
        <DigestValue>eW8=</DigestValue>
      </Reference>
    </SignedInfo>
  </Signature>
  [...]

Vor dem Signieren werden die Daten kanonisiert, logisch äquivalente Dokumente haben dadurch die gleiche Signatur. Von den folgenden Elementen

<Thing A="1" B="2">Hallo!</Thing>
<Thing B="2" A="1">Hallo!</Thing>
<Thing B="2" A="1">Hallo!<!--Kommentar!--></Thing>

sind die ersten beiden (sie entsprechen jeweils <Thing>Hallo!</Thing>) und die letzten beiden (entsprechen <Thing B=“2″ A=“1″>Hallo! </Thing>) logisch äquivalent.

Bei der Auswertung der Daten müssen die APIs auf den Text zwischen den Tags, den sog. InnerText, zugreifen. Das ergibt bei den verschiedenen SAML APIs zum Teil unterschiedliche Ergebnisse. So sind

<NameID>kelbyludwig</NameID>

und

<NameID>kelbyludwig</NameID>

logisch äquivalent, der InnerText ist aber im ersten Fall immer kelbyludwig, im zweiten Fall kelby. Kelby Ludwig vermutet, dass das an der Repräsentation als Baum liegen könnte. Das erste Element könnte als

ElementNode: NameID
|_ TextNode: "kelbyludwig"

dargestellt werden, das zweite als

ElementNode: NameID
|_ TextNode: "kelby"
|_ CommentNode: "comment!"
|_ TextNode: "ludwig"

Das kann man so machen (Ruby REXML macht es z. B. so, dort ist es aber auch so dokumentiert), sollte es aber im Interesse der Sicherheit nicht tun. Denn so ist es möglich, durch geschickte Änderungen Manipulationen an den Dokumenten vorzunehmen, ohne die Signatur ungültig zu machen. Ein möglicher Angriff könnte folgendermaßen aussehen: Gegeben sei ein NameID-Tag wie z. B.

<NameID>
  admin@opfer.example.boese.example
</NameID>

Der Angreifer fügt in den InnerText einen Kommentar ein:

<NameID>
  admin@opfer.example<!-- Vom Angreifer eingefuegt -->.boese.example
</NameID>

Der Kommentar beeinflusst die Signatur nicht, die bleibt unverändert gültig. Bei der Auswertung wird aber alles ab dem Start des Kommentars abgeschnitten, sodass der InnerText des Tags admin@opfer.example ist. Ein bösartiger Benutzer kann sich also mit seinen Credentials unter einem anderen Benutzernamen einloggen. Von dieser Schwachstelle waren mehrere Open-Source-Libraries und mehrere SSO-Lösungen wie z. B. GitLab und Shibboleth betroffen, sie wurden aber vor ihrer Vorstellung behoben. Wie ein Angriff ablaufen kann, hat Kelby Ludwig am Beispiel von GitLab gezeigt.

Schlimmer geht immer, so auch hier

Manche Identity-Provider erlauben es den Benutzer, sich selbst zu registrieren. Werden dabei Benutzereingaben mit der SSO-Identität zusammengefasst (was man als Mutable Identity bezeichnet) kann ein Angreifer die obige Schwachstelle besonders leicht ausnutzen und sich als ein anderer Benutzer ausgeben. Ein betroffener Identity-Provider ist das SSO-Feature von LastPass Enterprise, bei dem die NameID an die E-Mail-Adresse gebunden sein kann und Benutzer die E-Mail-Adresse ändern dürfen. Das ist an sich noch keine Schwachstelle, wird aber in Kombination mit einem verwundbaren Service-Provider problematisch.

Nehmen wir mal an, der Benutzer mit der E-Mail-Adresse opfer@unternehmen.example hat einen LastPass-Enterprise-Account. Der Angreifer kann sich dann mit der E-Mail-Adresse opfer@unternehmen.example.angreifer.example registrieren und sie danach bei einem Service-Provider durch Einfügen eines Kommentars in opfer@unternehmen.example<!– –>.angreifer.example ändern. Ich nehme an, Sie erkennen das Problem: Der Angreifer kann sich danach gegenüber dem betroffenen Service-Provider mit seinen Zugangsdaten als opfer@unternehmen.example authentifizieren.

OAth

Kommen wir noch kurz zu einer bereits in einem eigenen Artikel behandelten SSO-Lösung: OAuth. Diese Lösung habe ich bereits im Windows Developer 9.2018 [2] beschrieben. Hier möchte ich noch eine Reihe inzwischen weitgehend behobener Schwachstellen erwähnen: Ronghai Yang und Wing Cheong Lau haben auf der Black Hat Europe 2016 Schwachstellen bei der Nutzung von OAuth 2.0 durch eine Vielzahl von Mobile-Apps präsentiert. Im Wesentlichen geht es dabei darum, dass der Serverteil der App dem Mobile-Teil zu sehr vertraut, der sich wiederum bei der Authentifizierung auf möglicherweise manipulierte Informationen der Mobile-App des Identity-Providers verlässt. Das kann ein Angreifer ausnutzen, um sich unbemerkt und ohne Beteiligung des Opfers in dessen Mobile-App-Account einzuloggen.

Insellösungen

Außer diesen Standards gibt es auch Insellösungen wie z. B. Log-in mit Facebook oder dessen Google-Pendant. Dabei sammeln die Anbieter im Allgemeinen fleißig Informationen über die Benutzer und die von denen genutzten Dienste, siehe z. B. für Facebook. Dass diese Daten dann auch bei Dritten landen, sollte jedem klar sein [3]. Beim Einsatz von offenen Standards wie OAuth ist diese Datensammelei zumindest nicht im Standard vorgesehen, was einen böswilligen Anbieter natürlich nicht daran hindert, sich selbst etwas auszudenken, um seine Benutzer zu beobachten. Aber das muss er dann schon um den Standard herum basteln, und das wird in der Regel schnell auffallen, woraufhin sich die Benutzer dann ziemlich schnell absetzen dürften.

Fazit

SSO-Lösungen sind bequem und erhöhen oft auch die Sicherheit, da sich die Benutzer statt vieler verschiedener Zugangsdaten nur die für den SSO-Dienst merken müssen. „Oft“ deswegen, weil das natürlich nur gilt, wenn die SSO-Zugangsdaten sicher sind und wenn die dadurch eingesparten Zugangsdaten unsicher wären. Beispielsweise, weil identische Daten für mehrere Dienste verwendet oder unsichere Passwörter gewählt werden, wie es leider so oft der Fall ist.

Ansonsten sieht es bei der Sicherheit der SSO-Lösungen recht gut aus. Die sind natürlich ein verlockendes Ziel für Angreifer, wie z. B. ein Angriff auf OneLogin  zeigt. Aber zumindest die auf den Konferenzen vorgestellten Angriffe erfordern meist einen bösartigen Benutzer oder haben andere Einschränkungen, die Angriffe unwahrscheinlicher bzw. schwieriger machen.

Mit einer Ausnahme: Der von Dirk-Jan Mollema beschriebene Angriff auf/über Exchange-Server ist auch mit zum Zeitpunkt der Veröffentlichung des Angriffs und dem Schreiben dieses Artikels aktuellen Exchange-Versionen möglich, ein Patch steht noch aus. Aber Dirk-Jan Mollema hat einige Workarounds veröffentlicht.

 

Links & Literatur

[1] Eilers, Carsten: „Angriffsziel Active Directory“, Windows Developer 6. 2018
[2] Eilers, Carsten; Windows Developer 9.2018: „Von Semantik und Tokens“
[3] Eilers, Carsten; Windows Developer 2.1019: „Kein Buch mit sieben Siegeln – Was Facebook alles über Sie weiß, und woher es das weiß“

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -