9
Lustiger Bug in Windows. Hat jemand Lust, mitzuspielen?
Moin Kollegen.
Ich dachte bislang, tpm-basierte, virtuelle SmartCards (TPMVSC) wären eine feine Sache für manche Anwendungsfälle.
Bedingt durch ein Problem, welches hier gerade einen Rollout gestoppt hat, musste ich mich noch einmal intensiv damit beschäftigen und staune bei einer Testreihe gerade Bauklötze: Durch bloßen Zufall habe ich mich bei einer PUK-Operation vertippt und siehe da: eine falsche PUK entsperrte die virtuelle SmartCard erfolgreich!
Nach ein paar weiteren Tests kann ich schon gewisse Muster erkennen, welche PUKs zusätzlich zur richtigen funktionieren:
Die 10., 14., 26., 30., 42. und 46. Stelle der PUK erlauben es, hier verkehrte Ziffern einzutragen... aber nicht irgendwelche: es muss genau um 1 niedriger sein, als die eigentlich vorgesehene Ziffer.
Auf zu einem Beispiel:
Smartcard erstellt über:
Daraufhin muss der adminkey (=PUK) eingetippt werden. Hier nahm ich (willenlos 48 Stellen eingehämmert):
https://web.archive.org/web/20190713215310/http://secadmins.com/wp-conte ...
(Beschreibung leider nur noch im Archiv unter https://web.archive.org/web/20231002011950/http://secadmins.com/index.ph ... )
So, zur Sache. Erwartet wäre also folgender Erfolg:
Wie gesagt: es scheint Muster zu geben wie oben angedeutet.
Wer spielt mit und findet noch weitere mögliche PUKs?
Wer hat eine Erklärung? Dass die oben genannten Positionsnummern paarweise jeweils um 16 auseinanderliegen, kann wohl kein Zufall sein.
PS: dies als Kandidaten für einen Bug Bounty einzureichen, dürfte sinnlos sein, denn das habe ich bereits getan
Ich dachte bislang, tpm-basierte, virtuelle SmartCards (TPMVSC) wären eine feine Sache für manche Anwendungsfälle.
Bedingt durch ein Problem, welches hier gerade einen Rollout gestoppt hat, musste ich mich noch einmal intensiv damit beschäftigen und staune bei einer Testreihe gerade Bauklötze: Durch bloßen Zufall habe ich mich bei einer PUK-Operation vertippt und siehe da: eine falsche PUK entsperrte die virtuelle SmartCard erfolgreich!
Nach ein paar weiteren Tests kann ich schon gewisse Muster erkennen, welche PUKs zusätzlich zur richtigen funktionieren:
Die 10., 14., 26., 30., 42. und 46. Stelle der PUK erlauben es, hier verkehrte Ziffern einzutragen... aber nicht irgendwelche: es muss genau um 1 niedriger sein, als die eigentlich vorgesehene Ziffer.
Auf zu einem Beispiel:
Smartcard erstellt über:
tpmvscmgr.exe create /name tpmvsc /pin prompt /adminkey prompt /generate /pinpolicy minlen 6156728544855555584556544587885252565585555454565
Als PIN nahm ich111111
für das Zurücksetzen der PUK auf der Kommandozeile nutzte ich scutil.exe von hier:https://web.archive.org/web/20190713215310/http://secadmins.com/wp-conte ...
(Beschreibung leider nur noch im Archiv unter https://web.archive.org/web/20231002011950/http://secadmins.com/index.ph ... )
So, zur Sache. Erwartet wäre also folgender Erfolg:
scutil unblockpin 156728544855555584556544587885252565585555454565 111112
Success!
Ich stieß auf den Bug, als ich zufällig in der Zeile einmal Backspace gedrückt habe und eine 5 gelöscht hatte und ich mich dann beim Korrigieren vertippte und versehentlich eine 4 eintrug auf der Position 42 der PUK:Success!
scutil unblockpin 156728544855555584556544587885252565585554454565 111113
Success!
Wow... Microsoft, immer eine sichere Sache.Success!
Wie gesagt: es scheint Muster zu geben wie oben angedeutet.
Wer spielt mit und findet noch weitere mögliche PUKs?
Wer hat eine Erklärung? Dass die oben genannten Positionsnummern paarweise jeweils um 16 auseinanderliegen, kann wohl kein Zufall sein.
PS: dies als Kandidaten für einen Bug Bounty einzureichen, dürfte sinnlos sein, denn das habe ich bereits getan
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 51361940872
Url: https://administrator.de/contentid/51361940872
Printed on: April 27, 2024 at 07:04 o'clock
9 Comments
Latest comment
PS: dies als Kandidaten für einen Bug Bounty einzureichen, dürfte sinnlos sein, denn das habe ich bereits getan face-wink
Ich wünsche einen Haufen Cash!Nice find. Ich spiele morgen damit etwas herum :D
Gruß
Danke. Ich befürchte nur, dass jemand kommt und sagt "works as designed", zumal es ja Recht unkritisch ist, falls es bei dem gefundenen Muster bliebe und nicht tiefer liegt. Das wären bislang 2 hoch 6 verschiedene PUKs, die funktionieren - bei einem PUK-Raum von 16 (Hex!) hoch 48 möglichen PUKs wäre das quasi irrelevant.
zumal es ja Recht unkritisch ist
Mh, jaein. nen kleines Pythonscript ala brute force.. könnte da schon böse werden.works as designed
Klingt nach M$ :DViel Erfolg!
1
Ja, scheint mir so (ohne das jetzt selbst getestet oder mit offenen Implementierungen verglichen zu haben).
Es handelt sich ja um die direkte Eingabe eines kryptografischen Schlüssels, d.h. die Daten unterliegen keiner Schlüsselableitung mehr, sondern umgekehrt den Limitationen des Algorithmus.
Der 24-Byte lange Schlüssel muss für 3DES um 24 Bit gekürzt werden. Um dem Nutzer eine Eingabe über den ganzen Zahlenraum zu gewähren, können keine Paritätsbits Anwendung finden, und ist das Ignorieren der niedrigsten Bit eines Schlüssel-Bytes ein zulässiger Weg.
Dein Beispiel betrifft ein solches Bit. Funktioniert z.B. als dritte Option 156728544855555584556544587885252564585555454565 ?
Allerdings deckt es sich nicht ganz mit dem Bericht über Änderbarkeit genau der anderen Stellen, es kommt ja auf den Eingabewert bzw. den Binärübertrag an. Kann sein, das MS da noch einen Quirk eingebaut hat, aber eher dürfte es Zufall gewesen sein.
Grüße
Richard
Ah, der Durchblicker
Ja, das klingt plausibel. Und auch dein Beispiel funktioniert: du hast die PUK an Position 36 um 1 erhöht. Wie kamst Du darauf und welche anderen Positionen würden auch mit +1 laufen?
Aber ganz egal, wieviel kleiner der Raum dadurch nun wird: ich schätze mal, mein Zufallsfund kommt fast einem 6er im Lotto gleich von der Wahrscheinlichkeit her.
Ja, das klingt plausibel. Und auch dein Beispiel funktioniert: du hast die PUK an Position 36 um 1 erhöht. Wie kamst Du darauf und welche anderen Positionen würden auch mit +1 laufen?
Aber ganz egal, wieviel kleiner der Raum dadurch nun wird: ich schätze mal, mein Zufallsfund kommt fast einem 6er im Lotto gleich von der Wahrscheinlichkeit her.
Du liegst mit "um 24 Bit kürzen" wohl richtig.
Ich konnte erfolgreich testen, dass die folgenden 24 Modifikationen (Stelle +/-1) zulässig sind (auch in Kombination):
2-1
4+1
6-1
8+1
10-1
12+1
14-1
16+1
18-1
20+1
22-1
24+1
26-1
28+1
30-1
32+1
34-1
36+1
38-1
40+1
42-1
44+1
46-1
48+1
Ich konnte erfolgreich testen, dass die folgenden 24 Modifikationen (Stelle +/-1) zulässig sind (auch in Kombination):
2-1
4+1
6-1
8+1
10-1
12+1
14-1
16+1
18-1
20+1
22-1
24+1
26-1
28+1
30-1
32+1
34-1
36+1
38-1
40+1
42-1
44+1
46-1
48+1
Quote from @DerWoWusste:
Ja, das klingt plausibel. Und auch dein Beispiel funktioniert: du hast die PUK an Position 36 um 1 erhöht. Wie kamst Du darauf und welche anderen Positionen würden auch mit +1 laufen?
Ja, das klingt plausibel. Und auch dein Beispiel funktioniert: du hast die PUK an Position 36 um 1 erhöht. Wie kamst Du darauf und welche anderen Positionen würden auch mit +1 laufen?
Wenn du nach Binär konvertierst: https://gchq.github.io/CyberChef/#recipe=From_Hex('None')To_Bi ...
und wieder zurück: https://gchq.github.io/CyberChef/#recipe=From_Binary('Space',8 ...
...müsste das letzte Bit eines jeden Bytes ignoriert werden, also geflippt werden können.
1nen kleines Pythonscript ala brute force.. könnte da schon böse werden.
Nicht wirklich, da die virtuelle Smartcard ja tpm-basiert ist, macht sie nach 32 Versuchen permanent dicht.
Da keine weiteren Beiträge kommen, stelle ich die "Forschungen" ein und stelle fest: das gehört wohl so.
Danke @c.r.s.
Danke @c.r.s.