Letzte Woche habe ich meine ersten zwei Bug-Bounty-Reports eingereicht. Keiner davon hat einen Bounty bekommen. Und trotzdem war es einer der wertvollsten Lernschritte seit Beginn meiner Android Security Journey.
Der Moment, auf "Submit" zu drücken
Es fühlt sich merkwürdig an. Man hat einen potenziellen Bug gefunden, alles notiert, den Report formuliert – und dann ist da dieser Button. Submit. Ein mulmiges Gefühl, weil man weiß: Ein Mensch auf der anderen Seite wird das lesen und beurteilen. Ein Triager, der täglich echte Sicherheitslücken sieht.
Ich habe gedrückt. Zweimal. Und ich habe beide Male etwas Wichtiges gelernt.
Was ich gemeldet hatte – und was fehlte
Beide Findings drehten sich um Intent-basierte Angriffsvektoren auf Android. Im Kern: Ich hatte mit einer selbst geschriebenen Angreifer-App eine andere, fremde App geöffnet – über einen exported Activity oder einen unsicheren Deep Link.
Aus meiner CTF-Sicht war das ein Fund. In CTF-Challenges ist genau das oft die Lösung: Komponente ist exported, du kannst sie aufrufen, Challenge solved.
Das Problem: Der Triager hat nachgefragt – und ich hatte keine Antwort. "What is the actual impact for the end user?"
Ich konnte keine geben. Denn die ehrliche Antwort war: Ich habe die App geöffnet. Das ist alles. Kein Datenleck, kein Privilege Escalation, keine Möglichkeit, Nutzerdaten zu stehlen, keine Übernahme eines Accounts. Nur: App offen.
Das reicht nicht. Nicht im echten Bug Bounty.
Die erste große Erkenntnis: Impact ist alles
Im CTF-Kontext reicht es, eine Schwachstelle zu finden. Im Bug Bounty musst du zeigen, was ein echter Angreifer damit tun kann. Der Unterschied ist riesig.
Eine exported Activity ohne Impactnachweis ist kein Bug Report. Es ist eine Beobachtung.
Impact bedeutet: Was passiert konkret für den Nutzer oder das Unternehmen? Kann ein Angreifer Nachrichten abgreifen? Kann er Tokens stehlen? Kann er einen OAuth-Flow kapern? Kann er den Nutzer zu einer gefährlichen Aktion verleiten? Oder – und das war mein Fall – passiert eigentlich nichts Schlimmes?
Wenn die Antwort auf all diese Fragen "nein" ist, hat man keinen Bug Bounty-fähigen Fund – auch wenn die technische Beobachtung korrekt ist.
Die zweite Erkenntnis: Echte Manifests sind eine andere Welt
In CTF-Apps ist die AndroidManifest.xml übersichtlich.
Vielleicht 30, 40 Zeilen. Eine exported Activity, ein verdächtiges Permission – fertig.
Die Schwachstelle ist fast schon markiert.
In produktiven Apps sieht das anders aus. Das Manifest einer echten App kann hunderte von Zeilen umfassen. Dutzende Activities, Services, Receiver, Permissions – viele davon aus Third-Party-SDKs, die gar nichts mit der eigentlichen App-Logik zu tun haben. Firebase, Adjust, Google Sign-In, Push-Notification-Frameworks – all das landet im Manifest.
Was ich gelernt habe: Nicht jede exported Komponente ist ein Bug. Viele sind absichtlich exported – weil sie von anderen Apps oder System-Komponenten aufgerufen werden sollen. Die Frage ist immer: Kann ich das missbrauchen? Und wenn ja, mit welchem Effekt?
Das klingt simpel, ist aber ein echter Mindset-Wechsel. Im CTF denkt man: "Ist das exported? → Exploit." Im Bug Bounty muss man denken: "Ist das exported? → Warum? Was passiert, wenn ich es aufrufe? Was kann ich übergeben? Was kann ich damit erreichen?"
Wie ein guter Bug-Bounty-Report aussieht – was ich jetzt verstehe
Früher dachte ich, ein Report ist eine kurze Beschreibung plus Screenshot. Jetzt weiß ich, dass ein guter Report eigentlich eine Geschichte erzählt:
- Title: Präzise und ohne Buzzwords. Was genau ist das Problem?
- Severity: Realistisch. Nicht alles ist Critical.
- Description: Was ist die Schwachstelle technisch, und wo liegt sie genau?
- Steps to Reproduce: Schritt für Schritt, reproducible. Kein Raten, kein "irgendwie".
- Impact: Das wichtigste Feld. Was kann ein echter Angreifer damit tun?
- Proof of Concept: Code, Screenshots, Video – irgendetwas Handfestes.
Alles andere – Einleitung, Kontext, Tool-Erklärungen – ist Beiwerk. Der Triager will wissen: Ist das real? Ist das ausnutzbar? Was ist der Schaden?
Was ich beim nächsten Mal anders mache
Bevor ich den nächsten Report einreiche, stelle ich mir selbst drei Fragen:
1. Kann ich den Angriff vollständig demonstrieren?
Nicht nur "ich kann die Komponente aufrufen" – sondern was passiert danach konkret.
2. Welchen Schaden hat ein echter Nutzer davon?
Datenverlust? Account-Kompromittierung? Oder nur: eine andere Activity öffnet sich?
3. Könnte ich das vor einem Publikum verteidigen?
Wenn ich selbst nicht sicher bin, ob es ein Bug ist – dann ist es wahrscheinlich keiner.
Kein Bounty, aber kein Versagen
Ich will ehrlich sein: Es ist ein komisches Gefühl, wenn eine Antwort kommt und der Bug wird als "Informational" oder "Not Applicable" eingestuft. Aber rückblickend war es genau das richtige. Wer nie einen schlechten Report einreicht, lernt nicht, was einen guten Report ausmacht.
Ich weiß jetzt:
- Wie man einen Bug-Bounty-Report strukturiert und einreicht
- Dass Impact der entscheidende Faktor ist – nicht die technische Beobachtung allein
- Dass echte App-Manifests eine ganz andere Analysearbeit erfordern als CTF-Challenges
- Dass der Triager kein Feind ist – er stellt Fragen, weil er dir helfen will, zu verstehen
Das nächste Finding wird besser. Und wenn nicht – dann lerne ich wieder etwas.
Wenn du gerade deine ersten Reports schreibst oder dich traust, es zu tun: Fang an. Ein schlechter Report, aus dem man lernt, ist besser als kein Report aus Angst.
— KenSySec