Penetrationstest von Autogram: Was in der App unentdeckt blieb

Bei Citadelo testeten wir den Desktop-Client, die mobile Anwendung und die serverseitigen Komponenten. Der schwerwiegendste Fund verbarg sich in etwas, das ein gewöhnlicher Nutzer kaum als möglichen Angriffsvektor betrachten würde.

Autogram von Slovensko.Digital und dessen Mitgliedsunternehmen Freevision entstand aus der Frustration über staatliche Tools für elektronische Signaturen, bei denen viele Menschen den Signaturvorgang abbrechen, bevor sie ihn abschließen. Slovensko.Digital ist eine Bürgervereinigung, die sich seit mehr als zehn Jahren für eine höhere Qualität staatlicher digitaler Dienste einsetzt, und Autogram ist eines ihrer eigenen Tools. Es erfüllt eine Aufgabe: Dokumente rechtsverbindlich zu signieren – und zwar verständlich, sowohl am Computer als auch auf dem Smartphone. Viele Menschen verlassen sich darauf, darunter auch Mitarbeiter von Citadelo. In der Cybersicherheit wird die Auswirkung einer Sicherheitslücke üblicherweise anhand gestohlener Daten oder eines ausgefallenen Dienstes gemessen. Hier ist sie anderer Art: Sie kann die Rechtsgültigkeit einer Signatur und damit den Nachweis darüber infrage stellen, wer was unterzeichnet hat.

Autogram hat dabei einen Vorteil, den die meisten von uns getesteten Anwendungen nicht haben. Es ist Open Source, wird in einem öffentlichen Repository entwickelt und seit Jahren von der slowakischen IT-Community freiwillig und kostenlos unter die Lupe genommen. Genau in einer solchen Umgebung sollten Fehler eigentlich von selbst gefunden werden. Uns interessierte, was übrig bleibt, wenn wir die Anwendung einem gezielten Penetrationstest unterziehen.

„Autogram hat rund 9.000 aktive Nutzer, und über die mobile Autogram-App werden durchschnittlich 100 Dokumente pro Tag signiert.“ Marek, Entwickler bei Slovensko.Digital

Wie wir die Desktop- und die mobile Anwendung einem Penetrationstest unterzogen haben

Das Projekt bestand aus zwei Teilen. Zunächst testeten wir den Desktop-Client nach der OWASP-Thick-Client-Security-Methodik. Anschließend folgte ein Penetrationstest der mobilen Anwendung einschließlich der serverseitigen Komponenten, die sie unterstützen, auf Grundlage der OWASP Mobile Top 10.

Die Serverseite besteht aus einer Web-API, mit der die mobile Anwendung kommuniziert. Vier der elf Findings aus dem mobilen Test befanden sich in der API und nicht in der Anwendung auf dem Smartphone.

Der mobile Teil bestand dabei nicht aus einer einzigen Anwendung, sondern aus vier separaten Komponenten: einer speziell für Android vorgesehenen Version, einer Version für iOS, einer gemeinsamen Version für beide Plattformen und der Server-API. Jede davon verfügt über eigene externe Schnittstellen. Deshalb ergaben sich beim mobilen Test deutlich mehr Findings als beim Desktop-Test. Wir testeten Mitte Mai 2026 die Version 1.5.0 (Build 49), also jene Version, die Nutzer zu diesem Zeitpunkt aus Google Play und dem App Store installiert hatten.

Auf den gesamten Code hatten wir denselben Zugriff wie jeder andere. Nicht nur die mobile Anwendung, sondern auch die serverseitigen Komponenten sind öffentlich zugänglich. Wir kombinierten automatisierte Tools mit manuellen Tests: Tools zeigen verdächtige Stellen auf, doch erst ein manueller Penetrationstest kann feststellen, welche davon tatsächlich ausnutzbar sind. Da Autogram kryptografische Operationen mit rechtlichen Konsequenzen durchführt, konzentrierten wir uns auf die Vertraulichkeit der Daten, die Integrität der Anwendung während der Laufzeit und die Widerstandsfähigkeit der Kommunikation zwischen den Diensten.

Penetrationstest des Desktop-Clients: ein Finding mit niedrigem Schweregrad

Beim Desktop-Client untersuchten wir lokal gespeicherte Daten, den Schutz des Anwendungsspeichers, die Verarbeitung und Vorschau von Dateien sowie die Frage, ob sich der Anwendung beim Start eine fremde Bibliothek unterschieben lässt. Alles hielt stand.

Das Ergebnis war eine Schwachstelle mit niedrigem Schweregrad. Damit Autogram ein Dokument signieren kann, das von einer Website gesendet wird, läuft auf dem Computer ein kleiner lokaler Dienst, der solchen Websites antwortet. Das ist beabsichtigt und kein Fehler. Dass jede Website mit diesem Dienst kommunizieren darf, ist eine bewusste Entscheidung der Entwickler, ohne die eine Integration mit anderen Diensten nicht funktionieren würde.

Das Problem lag darin, welche Informationen der Dienst zusätzlich preisgab. Jeder, der eine entsprechende Anfrage stellte, konnte die genaue Version der installierten Autogram-Anwendung sowie eine Liste der Treiber für die Kartenlesegeräte des Nutzers erfahren. Ein Angreifer kann so unbemerkt feststellen, was genau beim Opfer installiert ist. Erkennt er, dass das Opfer eine nicht aktualisierte Version mit einer bekannten Schwachstelle verwendet, kann er gezielt diese angreifen, statt blind vorzugehen.

„Wir sind auf eine Desktop-Anwendung gestoßen, die wirklich sicher war. Wie sich später herausstellte, hatte ein großer Teil der slowakischen IT-Community sie bereits vor uns freiwillig getestet, und noch mehr Menschen nutzen sie tatsächlich.“ Nazarii, Penetration Tester bei Citadelo

Warum die Sicherheit mobiler Anwendungen eine andere Disziplin ist als Desktop-Sicherheit

Öffentlich zugänglicher Code hat seine Grenzen, und die mobile Anwendung zeigte uns genau, wo diese liegen. Code ist ein Bauplan. Aus ihm lässt sich ablesen, wie eine Funktion programmiert wurde. Was sie tatsächlich mit Daten aus einer anderen Anwendung macht, zeigt sich jedoch erst, wenn diese Daten wirklich bei ihr ankommen.

Eine mobile Anwendung ist schließlich nicht einfach eine Desktop-Anwendung mit kleinerem Bildschirm. Sie verfügt über Schnittstellen, die auf einem Computer nicht existieren: Intents, Content Provider, Deep Links und Systemdialoge zur Dateiauswahl. Über diese Mechanismen tauschen Anwendungen auf einem Smartphone Daten und Dateien untereinander aus. Gleichzeitig ist jeder davon ein Ort, an den auch eine Anwendung etwas senden kann, die dort niemand erwartet hat. Deshalb haben wir uns diese Stellen besonders genau angesehen.

Was der Penetrationstest der mobilen Anwendung aufgedeckt hat

Eine kritische Schwachstelle, eine Schwachstelle mit hohem Schweregrad, eine mit mittlerem Schweregrad, vier Findings mit niedrigem Schweregrad und vier informative Findings zur Verbesserung der allgemeinen Anwendungssicherheit.

Fast alle schwerwiegenden Findings hatten eine gemeinsame Ursache: Die Anwendung validierte die eingehenden Daten nicht.

Das kritische Finding betraf genau einen solchen Input, nämlich den Dateinamen. Autogram auf dem Smartphone ist so konzipiert, dass andere Anwendungen auf dem Gerät Dokumente an die App senden können, beispielsweise über E-Mail, einen Dateimanager oder die Funktion „Teilen“. Zusammen mit der Datei übernimmt Autogram auch deren Namen und speichert sie unter diesem Namen in seinen temporären Dateien.

Dieser Dateiname wurde jedoch nicht validiert. Autogram vertraute ihm. Eine schädliche Anwendung konnte deshalb anstelle eines Namens wie „vertrag.pdf“ einen Text übermitteln, der sich nicht wie ein Dateiname, sondern wie ein Pfad verhielt, der aus dem standardmäßigen Verzeichnis für temporäre Dateien herausführte. Autogram verwendete ihn und speicherte die Datei dort, wohin der Dateiname verwies. Dadurch ließ sich eine Datei im privaten Speicher von Autogram überschreiben, einschließlich jener Datei, in der die Anwendung ihre Einstellungen speichert. Darin befinden sich beispielsweise Informationen darüber, ob der Nutzer die Bedingungen akzeptiert hat, sowie Einstellungen für den Signaturvorgang.

Das Finding mit hohem Schweregrad führte in die entgegengesetzte Richtung – nach außen. Autogram vertraute Dateiverweisen, die von außen kamen, und überprüfte nicht, ob ein Verweis tatsächlich auf eine Datei zeigte, die der Nutzer sehen durfte. Dies ließ sich auf mehrere Arten ausnutzen.

Eine davon funktionierte folgendermaßen: Wenn Sie in Autogram auf dem Smartphone ein Dokument hinzufügen möchten, zeigt das Telefon eine Liste von Anwendungen an, aus denen eine Datei ausgewählt werden kann. Eine schädliche Anwendung kann sich in diese Liste eintragen und dabei wie eine der üblichen Optionen erscheinen. Wählt der Nutzer sie aus, kann sie Autogram anstelle eines Dokuments einen Verweis auf eine eigene geschützte Datei der App zurückgeben. Autogram selbst hat Zugriff auf diese Datei, öffnet sie und sendet sie an den Server. Dadurch verlässt die Datei den geschützten Speicher des Smartphones.

Das funktionierte sogar dann, wenn die Anwendung die Datei letztlich ablehnte. Einen nicht unterstützten Dateityp konnte Autogram auf dem Smartphone nicht anzeigen und zeigte dem Nutzer eine Fehlermeldung. Den Inhalt hatten wir zu diesem Zeitpunkt jedoch bereits in der Kommunikation mit dem Server gefunden. Die Fehlermeldung auf dem Bildschirm verhinderte den Datenabfluss also nicht.

Das Finding mit mittlerem Schweregrad betraf das Logging. Die Anwendung sendete Debug-Protokolle an einen externen Dienst zur Erfassung von Absturzberichten. In den Logs befanden sich jedoch auch sensible Daten: die Dokument-ID und der zugehörige Verschlüsselungsschlüssel. Nach außen übertragen wurden sie, wenn die Anwendung abstürzte, da die Protokolle zusammen mit dem Crash-Report versendet wurden. Wer über diese beiden Informationen verfügt, kann auf das Dokument zugreifen und benötigt dafür nichts Weiteres. Sie in einem Log zu speichern, ist praktisch dasselbe wie das Speichern von Zugangsdaten.

An einem der weniger schwerwiegenden Findings lässt sich gut erkennen, wie aus einem technischen Fehler ein Social-Engineering-Angriff werden kann. Die Anwendung zeigte den Inhalt eines Dokuments genau so an, wie sie ihn erhalten hatte – ohne Validierung. Dadurch ließ sich funktionsfähiges HTML einschleusen (HTML Injection), also Code, der auf dem Bildschirm wie ein echter Bestandteil der Benutzeroberfläche dargestellt wird. Ein Angreifer konnte so direkt über der offiziellen Signaturoberfläche einen gefälschten Dialog anzeigen, beispielsweise eine Aufforderung zur Eingabe der eID-PIN. Aus einem technischen Fehler wird damit eine vorbereitete Angriffsfläche für Phishing.

„Gut geschriebener Code, den viele Menschen geprüft haben, ist ein großer Vorteil. Er verrät jedoch nicht, wie eine Anwendung einen Input verarbeitet, der nicht die erwartete Form hat. Sicherheit lässt sich nicht einfach aus dem Code herauslesen. Man muss sie testen.“ Denis, Penetration Tester bei Citadelo

Die übrigen Findings betrafen fehlende Schutzmaßnahmen. Sie sind für sich genommen keine Schwachstellen, sondern zusätzliche Mechanismen, die einem Angreifer die Arbeit erschweren und ihn verlangsamen. Autogram erkannte beispielsweise nicht, ob das Gerät oder das Netzwerk kompromittiert worden war. Die meisten Menschen kennen das von Banking-Apps: Viele lassen sich auf einem Smartphone mit erweiterten Systemrechten gar nicht erst öffnen. Stellen sie fest, dass jemand in ihre Kommunikation eingreift, beenden sie die Verbindung selbstständig. Eine Anwendung mit solchen Schutzmechanismen kann Signaturvorgänge auf einem kompromittierten Gerät verweigern.

Was uns nicht gelungen ist

Das Ergebnis eines Tests besteht nicht nur aus einer Liste von Findings. Dazu gehört auch, was wir versucht haben und was nicht funktioniert hat. Gerade daran lässt sich erkennen, welche Schutzmechanismen der Anwendung standgehalten haben und was korrekt und sicher entwickelt wurde.

Den beliebigen Schreibzugriff auf Dateien konnten wir nicht weiter ausbauen. Bei Schwachstellen dieser Art gelingt es einem Angreifer manchmal, die vollständige Kontrolle über das Smartphone zu übernehmen. Dafür müsste er jedoch eine Bibliothek finden, die die Anwendung beim Start lädt und die sich überschreiben lässt. Autogram verfügt über keine solche Bibliothek, und wir fanden auch keinen anderen Weg, die vollständige Kontrolle über das Gerät zu erlangen.

Trotzdem stuften wir den Schweregrad nicht herunter. Das Finding blieb kritisch, da die Möglichkeit, Einstellungen einer Anwendung zu überschreiben, mit der Menschen rechtsverbindliche Dokumente signieren, aus unserer Sicht ein nicht akzeptables Risiko darstellt.

Auf die internen Schnittstellen der Anwendung konnten wir nicht direkt zugreifen. Autogram schützt sie vor anderen Anwendungen auf dem Smartphone. Das ist eine bewusste Designentscheidung und kein Zufall. Eine fremde Anwendung kann dort nicht direkt eine Datei anfordern. Wir mussten einen Umweg nehmen und eine interne Komponente von Autogram dazu bringen, die Datei für uns anzufordern.

Ähnlich verhielt es sich auf der Serverseite. Eine serverseitige Eingabevalidierung ist vorhanden. Als wir eine Datei übermittelten, die kein Dokument war, lehnte der Server sie ab. Die Kontrolle funktionierte genau wie vorgesehen.

Ein serverseitiges Finding ließen wir als offene Frage stehen. Der Server sendet Benachrichtigungen an eine Adresse, die das Gerät bei der Registrierung angibt, überprüft diese Adresse jedoch nicht. Zumindest theoretisch könnte sich dadurch eine Möglichkeit ergeben, eine Anfrage an ein Ziel zu senden, an das sie nicht gesendet werden sollte. Eine tatsächliche Ausnutzung konnten wir jedoch nicht nachweisen. Deshalb blieb das Finding auf der niedrigsten Schweregradstufe, verbunden mit der Empfehlung, dass die Entwickler es intern überprüfen. Findings, die wir nicht nachweisen können, bewerten wir nicht höher als gerechtfertigt.

Beide schwerwiegendsten Findings haben eine wichtige Einschränkung: Sie lassen sich nicht aus der Ferne auslösen. Der Angreifer muss eine eigene Anwendung auf dem Smartphone des Opfers installiert haben oder das Opfer muss einen Link des Angreifers öffnen. Das verringerte den Schweregrad nicht, denn schädliche Anwendungen werden auch außerhalb der offiziellen Stores Google Play und App Store verbreitet. Es schränkt lediglich den Kreis möglicher Angreifer ein: Es handelt sich nicht um eine zufällige Person aus dem Internet, sondern um jemanden, der bereits einmal Zugang zum Smartphone erlangt hat.

Ist das Signieren mit Autogram insgesamt also sicher? Diese Frage kann unser Test nicht beantworten. Wir testeten Autogram und den zugehörigen Server, nicht den elektronischen Personalausweis und auch nicht die staatlichen Komponenten, die die Signatur überprüfen. Diese Systeme gehören nicht Slovensko.Digital und werden von uns ohne Auftrag ihres Betreibers nicht getestet.

Penetrationstest vs. automatisierter Schwachstellenscan: Warum ein Scanner diese Findings nicht findet

Keines der beiden schwerwiegendsten Findings hätte allein durch einen Scanner bestätigt werden können. Genau darin liegt der Unterschied zwischen einem automatisierten Schwachstellenscan und einem manuellen Penetrationstest. Ein Scanner kann Code analysieren und eine verdächtige Stelle markieren. Er kann jedoch nicht nachweisen, dass sie tatsächlich ausnutzbar ist oder was ein Angreifer dadurch erreichen kann.

Um den beliebigen Schreibzugriff auf Dateien nachzuweisen, mussten wir eine eigene schädliche Anwendung entwickeln, die sich Autogram gegenüber als Quelle eines Dokuments ausgab und einen speziell präparierten Dateinamen übermittelte. Beim Abfluss von Dateien entwickelten wir eine eigene Anwendung zur Dateiauswahl und registrierten sie im System so, dass ein Nutzer sie anstelle der legitimen Anwendung auswählen konnte. Ein Scanner baut keinen Gegenspieler. Genau deshalb werden beim Ethical Hacking Angriffswerkzeuge speziell für ein konkretes Ziel entwickelt. Andernfalls lässt sich eine solche Schwachstelle weder bestätigen noch ausschließen.

Wie Slovensko.Digital die gefundenen Schwachstellen behoben hat – die Ursache statt elf einzelner Symptome

Ein Test hat erst dann einen Wert, wenn sich aufgrund seiner Ergebnisse etwas ändert. Hier lässt sich genau zeigen, was sich geändert hat.

Dank des öffentlich zugänglichen Codes blieben wir nicht beim Symptom des Problems stehen, sondern konnten bis zu seiner Ursache vordringen. Das ist der Unterschied zwischen der Empfehlung „Eingabevalidierung ergänzen“ und der exakten Identifizierung der Stelle, an der sie fehlt.

Die Entwickler bereiteten Fixes vor, die die von uns identifizierten Probleme beheben. Deshalb empfehlen wir, die Android-Version von Autogram auf dem Smartphone so schnell wie möglich zu aktualisieren.

Interessanter als die Geschwindigkeit ist dabei die Art der Behebung. Statt überall dort einen Patch einzubauen, wo sich das Problem zeigte, fügten die Entwickler eine zentrale Komponente hinzu. Diese ermittelt zunächst, wohin ein Dateiverweis tatsächlich führt, und überprüft anschließend, ob dieser Ort auf der Allowlist steht. Damit wurde die Ursache behoben und nicht nur eines ihrer Symptome.

Der Vorteil einer offenen Entwicklung besteht darin, dass jeder all das selbst überprüfen kann. Sie müssen weder uns noch den Entwicklern glauben – der Pull Request ist öffentlich. https://github.com/slovensko-digital/avm-app-flutter/pull/119 

Der kritische beliebige Schreibzugriff auf Dateien, der Abfluss lokaler Dateien, der Verschlüsselungsschlüssel in den Logs sowie die HTML Injection sind in der aktuellen Version von Autogram im App Store und bei Google Play behoben. Wenn Sie die Anwendung nutzen, achten Sie einfach darauf, dass sie auf dem neuesten Stand ist.

Ein Finding, das sich nicht sauber beheben lässt

Ein Finding bleibt offen, und das ist keine Nachlässigkeit. In unserem Bericht hat es den niedrigsten möglichen Schweregrad und wird lediglich als Empfehlung geführt. Trotzdem ist es vielleicht das interessanteste Finding des gesamten Tests.

Wenn jemand mit einem elektronischen Personalausweis signiert, gibt er zwei Codes ein, von denen ihm immer gesagt wurde, dass er sie niemandem verraten darf: den BOK und die Signatur-PIN für die qualifizierte elektronische Signatur. Die Anwendung muss diese Codes vorübergehend im Speicher halten, sonst könnte sie nicht mit ihnen arbeiten. Uns gelang es, den Speicher der laufenden Anwendung auszulesen, und wir fanden beide Codes dort in lesbarer Form.

Warum handelt es sich dann nur um ein informatives Finding? Weil der Angriff ein Smartphone voraussetzt, über das der Angreifer bereits die vollständige Kontrolle hat. Vor allem aber lässt sich ein solch sensibler Wert in der Programmiersprache, in der die Anwendung geschrieben wurde, nicht zuverlässig aus dem Speicher löschen. Das System gibt den Speicher frei, wenn es dies für angemessen hält, und ein Versuch, den Wert zu überschreiben, wird unter Umständen gar nicht ausgeführt, weil der Optimierer die Operation als unnötig entfernt. Eine wirklich saubere Lösung ist nur in Programmiersprachen möglich, die einen direkten Zugriff auf den Speicher erlauben.

Lässt sich das Problem also nicht durch Löschen beheben? Teilweise schon. Die Codes können für einen kürzeren Zeitraum und in einer Form im Speicher gehalten werden, die sich überschreiben lässt. Eine Garantie bietet das jedoch nicht. Der übrige Schutz besteht darin, zu verhindern, dass ein Angreifer überhaupt Zugriff auf den Speicher erhält. Dafür ist die Erkennung kompromittierter Geräte zuständig. Diese Funktion hatte die Anwendung nicht, und dies war ein separates Finding in unserem Bericht, ebenfalls auf informativer Ebene. Gerade diese beiden am wenigsten schwerwiegenden Findings erklären zusammen daher mehr als das kritische Finding. Die Grenze dessen, was sich hier beheben lässt, wird nicht vom Entwickler bestimmt, sondern von der Plattform, auf der die Anwendung läuft.

Was sollten Sie aus diesem Penetrationstest mitnehmen, wenn Sie eine eigene Anwendung entwickeln?

Wenn Sie eine Anwendung für mehrere Plattformen entwickeln, sollten Sie jede davon separat testen. Die Desktop-Version von Autogram war in einem guten Zustand, während die mobile Version ein kritisches Finding aufwies. Das war keine Nachlässigkeit. Die beiden Versionen verfügten schlicht über unterschiedliche Schnittstellen.

Der zweite Punkt ist konkreter. Wenn Ihre Anwendung Daten von anderen Apps auf einem Smartphone entgegennimmt, ist alles, was sie empfängt, potenziell vom Angreifer kontrollierter Input – nicht nur der Inhalt einer Datei. Dazu gehören auch der Dateiname und der Verweis auf die Datei. Fast alle unsere Findings hatten genau diese eine Ursache.

Drittens: Jeder Log-Eintrag, der einen Schlüssel oder Token enthält, sollte wie ein Zugangsdaten-Eintrag behandelt werden.

Und der wichtigste Punkt: Open-Source-Code ist ein großer Vorteil, den Autogram voll ausgeschöpft hat. Er ersetzt jedoch keinen Sicherheitstest. Der Code zeigt, was eine Anwendung tut. Ein Angriff zeigt, was sich mit ihr machen lässt.

Möchten Sie Ihre eigene Anwendung testen lassen?

Bei Citadelo führen wir Penetrationstests von mobilen Anwendungen, Webanwendungen und Infrastrukturen sowie Phishing-Simulationen und maßgeschneiderte Sicherheitsüberprüfungen durch. Wenn Sie etwas entwickeln, das mit Identitäten, Signaturen oder Zahlungen arbeitet, schreiben Sie uns, woran Sie arbeiten, und wir melden uns mit einem Vorschlag für den Testumfang.