Pentest-Umgebung für Android Apps

1. Angriffsziel SmartphonePentest Android

In meiner Tätigkeit als Penetrationstester habe ich mich vornehmlich auf die Aufdeckung und Analyse von Schwachstellen in Webanwendungen spezialisiert. Oftmals genügt eine unscheinbare Schwachstelle oder eine Unachtsamkeit in der Konfiguration, um sich Zugang zu hochsensiblen Daten zu verschaffen. Begünstigt durch die ständige und globale Erreichbarkeit stellen viele Webanwendungen bzw. serverseitige Anwendungen ein begehrtes Angriffsziel dar, die nach ihrer »feindlichen Übernahme« zu diversen Zwecken missbraucht werden.

Mit der flächendeckenden Verbreitung von Smartphones und Apps steigt die Anzahl von serverseitigen Anwendungen kontinuierlich an. Entwickler speichern Daten nicht nur auf dem Smartphone selbst, sondern lagern diese zunehmend in Server und »Cloud-Infrastrukturen« aus. Wir verlieren zunehmend die Kontrolle, wo unsere Daten letztendlich abgelegt werden und vor allem wie diese dort vor dem Zugriff fremder Blicke geschützt werden. In Anbetracht der intransparente Art und Weise, wie und wo Daten verarbeitet werden, sollten wir uns über eines klar werden: Wir haben schlichtweg keine Kontrolle mehr. Und durch die lokale Geräteverschlüsselung wiegen wir uns in eine trügerische Sicherheit.

Im vorliegenden Beitrag möchte ich euch einen Einblick in meine Android Pentest-Umgebung geben. Damit lassen sich sowohl client- als auch serverseitige Schwachstellen in Apps bzw. deren Infrastruktur erkennen und analysieren.

2. Client- und serverseitige Angriffe

Das Android OS bietet Entwicklern eine umfassende Palette, um Informationen zu verarbeiten und zu speichern. Informationen werden auf dem Gerät abgelegt, zwischen Anwendungen getauscht, auf Server hochgeladen oder neue Informationen von Servern empfangen. Wie die Datenverarbeitung erfolgt, ob die Daten verschlüsselt gespeichert werden bzw. die Verschlüsselung überhaupt korrekt implementiert wurde, dass können wir als Anwender nicht überblicken. Ebenso wenig wissen wir, ob die Abfrage neuer Informationen über einen verschlüsselten Kanal erfolgt oder praktisch von jedem im Klartext einsehbar ist. Wir müssen den Entwicklern demnach vertrauen, ob diese mit unseren Informationen sensibel umgehen bzw. dazu überhaupt in der Lage sind. Dabei stelle ich mir persönlich bspw. folgende Fragen:

  • Wie ausgeprägt ist die Sensibilität der Entwickler und Verantwortlichen gegenüber einer sicheren und auf den Zweck beschränkten Verarbeitung meiner Daten bzw. Informationen?
  • Wie hoch ist die Umsetzungsbereitschaft einer sicheren Programmierung bzw. wird diese bereits während der Entwicklung berücksichtigt?
  • Sofern die Bereitschaft für eine »sichere« Entwicklung vorhanden ist, schaffen es die Entwickler diese dann auch umzusetzen?
  • Wie reagieren die Verantwortlichen auf das Bekanntwerden einer Sicherheitslücke?
  • Wie schnell werden Schwachstellen geschlossen?
  • [ … ]

Um diese Fragen zu beantworten bzw. in der Praxis zu überprüfen, eignet sich bspw. ein Pentest. Auf Android bezogen lässt sich ein Pentest in zwei Hauptbereiche aufteilen:

  • Clientseitige Angriffe: Dieser Bereich umfasst »lokale« Schwachstellen, wie bspw. die unsichere Speicherung sensibler Informationen, im Quellcode auffindbare Passwörter, Manipulation von Activities, Broadcast-Receivern, etc.
  • Serverseitige Angriffe: Zu den bekannten Schwachstellen auf der Serverseite zählen bspw. XSS, SQL-Injections, die Umgehung der Autorisierung oder Authentifikation, etc.

Im vorliegenden Beitrag werde ich die Einrichtung einer Pentest-Umgebung anreißen, die sich für die Erkennung serverseitiger Angriffe eignet. Damit ist es möglich den ein- und ausgehenden Verkehr einer Android App zu untersuchen und Schnittstellen bzw. serverseitige Anwendungen zu identifizieren, die Daten verarbeiten, speichern oder die Apps mit neuen Informationen versorgen.

3. Aufbau einer Pentest-Umgebung

Als Basisumgebung nutze ich Kali Linux, das bereits viele Pentest-Tools mitbringt und im Zusammenspiel mit dem Android SDK keinerlei Probleme bereitet. Das Android SDK ist eine Grundvoraussetzung für die Durchführung eines Android Pentests, da es bspw. den Android Emulator oder das adb Tool beinhaltet. Übrigens genügt es vollkommen, die »SDK Tools Only« zu laden, denn das komplette Android Studio Package ist für unseren Zweck überdimensioniert.

Hinweis: In Kali Linux ist die Installation folgender Pakete notwendig lib32z1 lib32ncurses5 lib32stdc++6

3.1 Tools und kleine Helfer

Ergänzt wird Kali Linux bzw. das Android SDK um folgende Tools, die uns bei der Auffindung von Schwachstellen behilflich sein sollen:

  • Apktool: Liegt eine App nicht quelloffen vor, so müssen wir »Reverse Engineering« betreiben und das APK-File dekompilieren. Achtung: Es sollte zuvor immer geprüft werden, ob ihr zur Dekompilierung berechtigt seid
  • ApkAnalyser: Ein Tool zur Analyse der API-Verweise, Darstellung der App-Architektur und deren Abhängigkeiten
  • dex2jar: Ermöglicht die Konvertierung von *.dex Dateien in Java *.class Dateien (Gezippt als *.jar)
  • JD-GUI: Eine grafische Oberfläche zur Darstellung von Java Quellcode bzw. CLASS Dateien
  • Zed Attack Proxy / Burp Suite: Ein Vermittler bzw. Proxy zwischen Client und Server, mit dem wir Verbindungen abfangen und manipulieren
  • DB Browser for SQLite: Eine grafische Oberfläche zur Darstellung und Veränderung von SQLite Datenbanken
  • [ … ]

3.2 Android Emulator

Mit Hilfe des Android Emulators lässt sich das Android OS und seine Schnittstellen emulieren. Ursprünglich dient es Entwicklern als Testplattform für neue Apps oder als Möglichkeit bestehende Apps für kommende Android Versionen anzupassen. Ihr könnt damit unterschiedliche Android Versionen (bspw. 4.x oder 5.1.1) emulieren und euch Smartphones und Tablets in den verschiedensten Hardware-Kombinationen zusammenstellen, die sich bspw. in der Auflösung und Prozessor voneinander unterscheiden.

Achtet bei der Erstellung eines Geräts auf die Verwendung einer aktuellen Android-Version (Target Android 5.1.1), wenn ihr aktuelle Apps testen wollt. Diese sind auf älteren Android-Versionen oftmals nicht mehr lauffähig oder bietet lediglich einen eingeschränkten Funktionsumfang. Weiterhin solltet ihr darauf achten, eine SD Card zu emulieren. Ansonsten könnt ihr später keine Apps über adb auf das emulierte Gerät aufspielen. Im Rahmen unserer Pentest-Umgebung könnt ihr bspw. folgendes Gerät erzeugen:

Android Virtual Device

Hinweis: Wenn ihr im Anschluss euer virtuelles Gerät zum ersten Mal über den AVD Manager startet, kann dies zwischen 5 bis 20 Minuten in Anspruch nehmen.

3.3 Auf einen Blick

  • Sofern ihr Kali Linux nutzt, solltet ihr die Pakete lib32z1 lib32ncurses5 lib32stdc++6 nachinstallieren
  • Android SDK für das passende System herunterladen und entpacken
  • Android SDK Manager (android-sdk-linux/tools/android) aufrufen und eine aktuelle API (bspw. 5.1.1 – API 22) selektieren und herunterladen
  • Den AVD Manager (android-sdk-linux/tools/android avd) starten und ein virtuelles Android Gerät erstellen
  • Die unter Ziffer 3.1 genannten Tools herunterladen oder über das Debian-Paketmanagement installieren

4. Eine App auswählen

Bei der Auswahl einer App sind euch keine Grenzen gesetzt. Ihr könnt im Prinzip jede App aus dem Google Play Store »untersuchen« oder euch eine quelloffene App aus dem F-Droid Store herunterladen. Falls ihr euch für die Google Play Store Variante entscheidet, habt ihr zwei Möglichkeiten, um das APK-File auf dem virtuellen Gerät zu installieren:

  • Ihr könnt die Play Store App direkt im Emulator mit einem bestehenden Account verknüpfen und anschließend Apps aus dem Play Store herunterladen
  • Eine Alternative ist die Verwendung des APK-Downloaders, den ich bereits in der Artikelserie »Your phone – your data« vorgestellt hatte

Grundsätzlich empfehle ich euch allerdings den Download einer quelloffenen App. Das erspart euch das Dekompilieren mit dem Apktool und verletzt zudem kein Urheberrecht.

Soll eine kostenpflichtige App geprüft werden, so lasse ich mir diese direkt von den Entwicklern zukommen.

4.1 Apktool und das Android Manifest

Jede Android App beinhaltet ein Manifest im XML Format. Die Datei AndroidManifest.xml enthält die wichtigsten Informationen über eine App, die dem System vor dem Start einer Anwendung bekannt sein müssen. Zu den Informationen zählen bspw.:

  • Eine eindeutige ID für die Anwendung, die sich aus dem Java-Package Namen ableitet
  • Eine Auflistung aller Berechtigungen, um auf bestimmte Ressourcen des Geräts zuzugreifen (Sensorinformationen, persönliche Informationen, etc.)
  • Eine Auflistung aller Komponenten der Anwendung wie bspw. Broadcast-Receiver, Services, Activities usw.

Aus dem Manifest lassen sich wichtige Informationen gewinnen. Bei Open Source Android Apps können wir diese Datei jederzeit einsehen. Nicht jedoch bei proprietären Apps, die sich vor allem im Play Store finden lassen. Bevor wir auf die AndroidManifest.xml zugreifen können, müssen wir den folgenden Befehl benutzen:

apktool d APK-FILE

Anschließend erstellt das Apktool einen Ordner, der sich aus dem Java-Package Namen ableitet. Darin befinden sich neben dem AndroidManifest.xml auch Teile des dekompilierten Quellcodes der App. Im Folgenden ein Beispiel:

AndroidManifest.xml

Über die AndroidManifest.xml lässt sich zweifelsfrei erkennen, dass die App eine Vielzahl von Berechtigungen anfragt bzw. einfordert. Unter anderem darf sie »USB-Speicherinhalte ändern oder löschen«, »Audio aufnehmen« und »Systemeinstellungen ändern«. Besonders interessant ist allerdings die Berechtigung »Daten aus dem Internet abrufen« (android.permission.INTERNET), was auf die Kommunikation mit einem oder mehreren externen Servern schließen lässt. Wäre diese Berechtigung nicht vorhanden, dann könnten keinerlei serverseitigen Angriffe stattfinden, da die App keine Verbindung mit externen Netzteilnehmern initiiert.

4.2 Installation einer App

Bevor wir die externe Kommunikation einer App untersuchen können, müssen wir sie noch auf das virtuelle Gerät bzw. den Emulator übertragen. Mit dem Kommandozeilentool adb (Android Debug Bridge) ist das mit einem kurzen Befehl sogleich erledigt:

adb install APK-FILE

Solltet ihr die Emulation einer SD-Karte versäumt haben, so müsst ihr dies über den AVD Manager nachholen. An­dern­falls scheitert (jedenfalls bei mir) die Installation auf dem Gerät. Im DroidWiki sind übrigens die wichtigsten adb Befehle zusammengefasst.

5. Proxy

Den Netzwerkverkehr einer App können wir erst dann einsehen, wenn wir die Informationen in irgendeiner Form abfangen können. Dazu benötigen wir einen Proxy, der sozusagen als Vermittler zwischen App und dem Server dient. Er wird die Anfragen von der App entgegennehmen, um dann über seine eigene Adresse eine Verbindung zum Server herzustellen.

5.1 ProxyDroid

Mit der Kombination aus Burp Suite, ProxyDroid (nicht mehr verfügbar) und einem gerooteten Android lassen sich HTTP(S)-Verbindungen relativ einfach mitschneiden:

  • Installiert zunächst das Burp CA auf dem Gerät. Falls die Burp Suite bspw. auf 192.168.1.5:8080 lauscht, dann ruft die Adresse »http://192.168.1.1:8080/cert« direkt im Browser auf
  • Speichert die Datei auf der Festplatte und benennt die Datei in cacert.crt um
  • Anschließend übertragt ihr das Zertifikat mittels adb (adb push /PFAD/cacert.crt /storage/sdcard) auf euer virtuelles Android Gerät
  • Über Systemeinstellungen -> Sicherheit -> Von Speicher installieren -> /storage/sdcard/cacert.crt installiert ihr das soeben übertragene Zertifikat
  • Anschließend installiert ihr noch ProxyDroid und tragt die Adresse der Burp Suite ein
    • Proxy: 192.168.1.5
    • Port: 8080
    • Proxy-Type: HTTP

Wenn ihr jetzt noch ein Häkchen bei »Global Proxy« setzt werden alle HTTP(S)-Verbindungen (Port 80, 443) über die Burp Suite geleitet und ihr könnt den Netzwerkverkehr einsehen.

5.2 iptables

Mit Hilfe der ProxyDroid Lösung können wir lediglich Anfragen mitschneiden, die über Port 80 bzw. 443 ausgesendet werden. Alle anderen Netzwerkverbindungen können wir nicht einsehen. Das ist natürlich nicht ganz optimal, denn viele Apps beschränken sich bei der Kommunikation mit Servern nicht ausschließlich auf die Ports 80 und 443. Über iptables und einer passenden NAT– (SNAT / DNAT) oder MASQUERADING-Regel lässt sich dies allerdings auch lösen.

Um bspw. jeglichen XMPP-Traffic von Port 5222 über Burp zu leiten, genügen folgende Befehle direkt auf dem virtuellen Gerät:

iptables -t nat -A OUTPUT -p tcp --dport 5222 -j DNAT --to-destination 192.168.1.5:8080
iptables -t nat -A POSTROUTING -p tcp --dport 5222 -j MASQUERADE

Jegliche Netzwerkommunikation die für Port 5222 bestimmt ist, wird anschließend an 192.168.1.5:8080 weitergereicht. Wenn wir einen Blick auf das iptables Regelwerk werfen, erkennen wir die neu hinzugefügte DNAT-Regel:

iptables

Unterstütze den Blog mit einem Dauerauftrag!

Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.

Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.

Mitmachen ➡

5.3 Nicht Proxy fähige Apps

Wenn ihr in Burp keine Verbindungen im Proxy seht, dann aktiviert unter Proxy -> Options die Option »Support invisible proxying«.

Burp Proxy

In der Praxis unterscheidet man zwischen »Proxy-Aware« und »Non-Proxy-Aware«. Nicht Proxy fähige Apps wissen nicht, dass die Verbindung über einen Proxy geleitet wird. Mit Hilfe der Option »Support invisible proxying« ermöglichen wir diesen Apps eine direkte Verbindung zum Burp-Listener aufzubauen.

6. Rechtlicher Hinweis

Ein Penetrationstest (oder auch abgekürtzt Pentest genannt) ist ein auftragsgesteuerter Einbruch in ein oder mehrere Systeme. Zwischen Kunden und dem Pentester werden also Verträge geschlossen, die unter anderem eine Freistellungserklärung und Legitimation vorsehen sollte. Das bedeutet: Einfach mal so »drauf los hacken« solltet ihr tunlichst vermeiden. Andernfalls macht ihr euch strafbar. Das deutsche Strafgesetzbuch hält diesbezüglich einige Strafbarkeitstatbestände parat:

  • § 202a StGB »Ausspähen von Daten«
  • § 202b StGB »Abfangen von Daten«
  • § 202c StGB: »Vorbereiten des Ausspähens und Abfangens von Daten«
  • § 303a StGB »Datenveränderung«
  • [ … ]

Von serverseitigen Angriffen solltet ihr deshalb absehen. Diese dürfen erst dann durchgeführt werden, wenn ihr die Erlaubnis vom Betroffenen eingeholt habt. Zu den Informations- und Verzichtserklärungen regeln noch weitere Vereinbarungen, wie bspw. der Prüfungsplan (OWASP Testing Guide v4), den geregelten Ablauf eines Pentests.

Hinweis: Empfehlenswert ist das GoatDroid Project vom OWASP. Es bietet eine Lernumgebung, um client- und serverseitige Angriffe auszuprobieren bzw. kennenzulernen.

7. Fazit

Smartphones beinhalten eine Vielzahl persönlicher Informationen. Den Schutz dieser Informationen können wir alleine nicht leisten. Denn trotz Geräteverschlüsselung und einem aktuell gepatchten System spielen unsere installierten Apps eine entscheidende Rolle. Alleine von den Bewertungen im Google Play Store können wir nicht ableiten, ob eine App unsere Informationen sicher verarbeitet und speichert. Wir müssen den Entwicklern »blind« vertrauen und haben praktisch keine Kontrollmöglichkeiten.

Grundsätzlich sind Hersteller aus unterschiedlichen rechtlichen Gründen verpflichtet, insbesondere wenn sie mittels der Apps Daten von uns sammeln, entsprechende technische und organisatorische Maßnahmen zu treffen. Sie müssen sicherstellen, dass unsere Daten ausreichend geschützt sind. Daher sind sie eigentlich auch verpflichtet zu gewährleisten, dass die von ihnen angebotenen Apps sicher programmiert sind und deshalb keine Gefahr für den Datenschutz darstellen. Doch wie immer klaffen in der Praxis Theorie und Wirklichkeit weit auseinander. Vielmehr wird IT-Sicherheit und Datenschutz  von den meisten Herstellern, aus welchen Gründen auch immer, im Produktlebenszyklus nicht beachtet. So nehmen Hersteller / Anbieter bspw. vielfach keine pro-aktiven Maßnahmen wie bspw. eine Überprüfung des Quellcodes oder Pentests vor. Ferner berücksichtigen sie auch nicht die gesetzlichen Anforderungen an eine »datenschutzkonforme« App. Vielmehr »reift« die App meistens beim Kunden – kein Wunder also, dass wir ständig mit allerlei Schwachstellen und Data-Breaches konfrontiert werden.

Ich hoffe ich konnte euch einen kleinen Einblick in meine Android Pentest-Umgebung geben. Zu einem geeigneten Zeitpunkt werde ich euch demnächst eine Schwachstelle in einer App demonstrieren.

Bildquellen:

Bash: OpenClipart-Vectors, Creative Commons CC0

Über den Autor | Kuketz

Mike Kuketz

In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.

Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.

Mehr Erfahren ➡

SpendeUnterstützen

Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.

Folge dem Blog

Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:

Bleib aktuell ➡


Diskussion

5 Ergänzungen zu “Pentest-Umgebung für Android Apps”

  1. Comment Avatar Ein anonymer Verfasser sagt:

    Guten Tag Herr Kuketz und andere Kommentatoren,
    dies ist ein sehr hilfreicher Artikel um die Sicherheit bestimmter Apps zu überprüfen. Nun stellt sich aber die Frage was ,,wir“ als Nutzer tun können wenn sich herausstellt, dass die Sicherheit bestimmter Apps ,,problematisch “ ist. Das heißt, wenn diese zB. unsicher mit deren Server kommunizieren.

    • Comment Avatar Gerald Spyra sagt:

      Guten Morgen,

      so banal es klingen mag.
      Aber wenn man dieses von Ihnen beschriebene Verhalten von Apps feststellt, sollte man sich (in einem persönlichen Risikomanagement) fragen, ob man dieses Risiko tragen will oder nicht. Das ist eine sehr persönliche Entscheidung, die jeder mit sich selber ausmachen muss.
      Wenn man das Risiko nicht tragen will, dann sollte man diese App nicht nutzen und vielleicht auf weniger kommunikationsfreudige Apps z. B. im F-Droid-Store umsteigen.
      Grundsätzlich sollte man sich sowieso immer fragen, welche Apps man für seinen täglichen Gebrauch eigentlich wirklich braucht. Diese sollte man dann auch nur installieren…

      Viele Grüße
      Gerald Spyra

    • Comment Avatar Mike Kuketz sagt:

      Das hängt von der Perspektive ab.
      [1] Wenn jemand eine Schwachstelle findet, dann wäre der korrekte Weg diese dem Hersteller zu melden. Für solche Fälle kann man sich an »Vulnerability Disclosure Guidelines« orientieren.
      [2] Als Anwender bekomme ich oftmals gar nicht mit, dass eine Schwachstelle gemeldet wurde bzw. diese vielleicht vom Hersteller gefixt wurde. Um das herauszufinden muss ich dann wiederum in Changelogs wühlen und selbst da ist das nicht immer sauber aufgeführt.
      [3] Größere Schnitzer werden teilweise publik und auf diversen IT-Seiten bzw. Nachrichtenportalen diskutiert. Sollte ich als Anwender davon Wind bekommen, muss ich für mich persönlich entscheiden, ob ich jene App noch nutzen möchte oder womöglich auf eine Alternative umsteige. Aber auch das ist nicht so einfach, denn woher kann ich als Anwender nun wissen, ob die Alternative wiederum mit mehr Sorgfalt entwickelt wurde?

      Ich persönlich kann nur empfehlen, Open Source Apps aus dem F-Droid Store zu verwenden. Im Beitrag Anwendungen und Dienste nach meinem »Geschmack« habe ich einige vorgestellt. Aus eigener Erfahrung weiss ich leider: Gerade bei Closed Source Apps »pfuschen« Entwickler gerne was zusammen.

  2. Comment Avatar Ein anonymer Verfasser sagt:

    Guten Morgen,
    ich hatte meine Frage leider nicht präzise genug gestellt. Die Frage bezieht sich auf Apps auf die man nicht verzichten will (oder kann). Bis die Sicherheitslücken solcher Apps geschlossen werden (bzw. falls sie überhaupt geschlossen werden) kann das eine (un)gewisse Zeit in Anspruch nehmen. Besonders bei (closed-source)Apps, die nicht mehr weiterentwickelt werden, ist das ein Problem. Was kann man bis dahin ,,auf eigene Faust“ tun um diese Apps zumindest vorübergehend ,,sicher zu machen“? Könnte z.B. eine VPN-Verbindung helfen?

    • Comment Avatar Mike Kuketz sagt:

      Wenn eine App bspw. unverschlüsselt Daten austauscht und ich nicht möchte, dass diese von jedem im Internetkaffee mitgeschnitten werden, kann ich auf ein VPN zurückgreifen. Damit kann ich die »Symptome« lindern, aber nicht beseitigen. Letztendlich haben die Entwickler die Aufgabe die Schwachstelle zu fixen. Funktioniert das nicht, dann sollte man sich nicht stur an eine App oder Dienst klammern. Es gibt immer Alternativen.

HilfeWenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-Forum

Abschließender Hinweis

Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.

Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.