Archive for Februar 2018

Trusted Platform Module (TPM) unter Windows und SpecVersion ermitteln

13 Februar 2018

Um Passwörter und Geheimnisse abzusichern werden immer mehr Hardwaremodule eingesetzt. Eines dieser Module ist z. B. TPM. Die Aufgabe eines Trusted Platform Module ist es bestimmte Schlüssel und Geheimnisse abzuspeichern. Es ist zwar meist ein Hardwaremodul aber es kann im Innern doch auch wieder per Software updatebar sein. Ich hatte bereits vor Jahren versucht TPM unter Hyper-V mit ans laufen zu bekommen https://newyear2006.wordpress.com/2014/05/15/hyper-v-vms-trusted-platform-module-und-das-problem-mit-den-virtual-smart-cards/.  Damals gab es aber noch keine Unterstützung im Hyper-V. Dies sieht heute anders aus. Dadurch kann man sich nun mit TPM beschäftigen, ohne sich viel Gedanken machen zu müssen. Wo TPM bei Windows 10 zum Einsatz kommt, kann man hier nachlesen: https://docs.microsoft.com/en-us/windows/security/hardware-protection/tpm/how-windows-uses-the-tpm.

Eine Frage die sich schnell ergibt, wenn man sich damit beschäftigt, ist, welche Version hat man eigentlich? Gängig sind Version 1.2 oder 2.0. Ruft man mittels TPM.MSC also die “Trusted Platform Module”-Management (TPM)-Konsole auf, dann kann man dort unter TPM-Herstellerinformationen die Spezifikationsversion einsehen. Schön, aber wie geht das auch per Commandline? Da gibt es eigentlich das Cmdlet Get-Tpm:

PS > Get-Tpm

TpmPresent                : True
TpmReady                  : True
ManufacturerId            : 1297303124
ManufacturerIdTxt         : MSFT
ManufacturerVersion       : 8213.275
ManufacturerVersionFull20 : 8213.275.21.18466

ManagedAuthLevel          : Full
OwnerAuth                 : R8yRy4e6DfK2hDS/EbQxdhA=
OwnerClearDisabled        : False
AutoProvisioning          : Enabled
LockedOut                 : True
LockoutHealTime           : 10 minutes
LockoutCount              : 0
LockoutMax                : 31
SelfTest                  : {}

Hier hätte ich erwartet, dass SpecVersion auftaucht, doch leider tut sie es nicht. Ok wir haben ja Powershell, vielleicht versteckt sich die Info woanders:

Get-Command -Module TrustedPlatformModule -ParameterName *spec*

Aber da kommt leider auch nix raus. Zumindest in der Version 2.0 der Cmdlets aus dem TrustedPlatformModule-Modul.

Also was tun? Wie immer liegt die Lösung im WMI, denn dort kann man die Klasse Win32_Tpm finden, zunächst brauchen wir aber eine einfache Möglichkeit um alle Namespaces zu durchlaufen:

Function Get-NamespaceRecursive ($namespace) {
$nss=Get-CimInstance -Namespace $namespace -ClassName __NAMESPACE
$nss | % {"$namespace/$($_.Name)"; Get-NamespaceRecursive "$namespace/$($_.Name)" }
}

Mit dieser können wir mittels diesem Aufruf alle verfügbaren Namespaces ermitteln und dort nach TPM Ausschau halten:

$ns=Get-NamespaceRecursive "root"
$tpm=$ns| % {Get-CimClass -Namespace $_ -ClassName *} | where CimClassName -match tpm

   NameSpace: ROOT/CIMV2/Security/MicrosoftTpm

CimClassName                        CimClassMethods      CimClassProperties
————                        —————      ——————
Win32_Tpm                           {IsEnabled, IsOwn… {IsActivated_Initial…

Damit erhalten wir zwei Treffer, einer davon Win32_TPM. Diesen schauen wir uns genauer an:

(Get-CimClass -Namespace ROOT/CIMV2/Security/MicrosoftTpm -ClassName Win32_Tpm).CimClassProperties | where name -match specversion

Name               : SpecVersion
Value              :
CimType            : String
Flags              : Property, NullValue
Qualifiers         : {Description, Implemented}
ReferenceClassName :

Also Volltreffer. Es gibt sie also, die gesuchte Information.

Um in Zukunft die SpecVersion des TPM zu ermitteln verwendet man diesen einfachen Aufruf:

wmic /namespace:\\root\CIMV2\Security\MicrosoftTpm path Win32_Tpm get /value

IsActivated_InitialValue=TRUE
IsEnabled_InitialValue=TRUE
IsOwned_InitialValue=TRUE
ManufacturerId=1297303124
ManufacturerIdTxt=MSFT
ManufacturerVersion=8213.275
ManufacturerVersionFull20=8213.275.21.18466
ManufacturerVersionInfo=496f5420536f6674776172652054504d00
PhysicalPresenceVersionInfo=1.3
SpecVersion=2.0, 0, 1.15

Ups, das war der falsche Befehl 🙂 Bin da etwas in alte Zeiten ohne Powershell abgerutscht… Trotz allem könnte obiger Befehl in Situationen wichtig sein, wenn man mittels WinPE oder WinRE unterwegs ist und kein Powershell an Bord hat. In diesem Fall sollte man aber noch drvload x:\windows\inf\tpm.inf im Hinterkopf behalten, denn ohne Treiber geht evtl. nix. Zurück aber zum Thema.

Gemeint war dieser:

(Get-CimInstance -Namespace ROOT/CIMV2/Security/MicrosoftTpm -ClassName Win32_Tpm).SpecVersion
2.0, 0, 1.15

Schön nun haben wir Version 2.0, 0, 1.15 und das bedeutet nun? Ist es 2.0 oder eine verkappte 1.2 Version? Tja, Aufklärung gibt es auf der Microsoft Seite zur Win32_Tpm-Klasse https://msdn.microsoft.com/en-us/library/windows/desktop/aa376484, dort steht:

The version of the Trusted Computing Group (TCG) specification that the TPM supports. This value includes the major and minor TCG specification version, the specification revision level, and the errata revision level. All values are in hexadecimal. For example, a version information of "1.2, 2, 0" indicates that the device was implemented to TCG specification version 1.2, revision level 2, and with no errata.

When the data is unavailable, "Not Supported" is returned.

Aha, wir bekommen also ziemlich viel geboten. Nur stellt sich die Frage, was für Erratas und Revisionen gibt es? Nun, wenn man beim Informationsimperium anfragt, dann bekommt man diese Seite geliefert: https://trustedcomputinggroup.org/tpm-library-specification/. Übrigens hatte ich die Trusted Computing Group schon mal mit SED im Programm: https://newyear2006.wordpress.com/2016/10/01/self-encrypting-drives-sed-und-probleme-mit-gelschten-bitlocker-partitionen/.

Obige SpecVersion mit 2.0, 0, 1.15 sagt also aus, dass wir es mit der 2.0er-Familie, dem Level 0 und der Revision 01.16 vom Oktober 2014 zu tun haben. Wobei die Angaben sich mit der Beschreibung von Microsoft oben nicht decken.

Hier die aktuell bekannten Versionen:

Familie/Version Level Revision vom
2.0 0 01.38 September 2016
2.0 0 01.16 Oktober 2014
2.0 0 00.99 Oktober 2013
2.0 0 00.96 März 2013
1.2 2 116  
1.2 2 103  
1.2   94  
1.2   85  
1.2   62  
1.1b      

Die Werte für 1.2 sind von hier: https://trustedcomputinggroup.org/tpm-main-specification/.

Wer sich tiefergehend mit TPM 2.0 beschäftigen möchte, der sollte sich unbedingt die Architekturbeschreibung und die Einrichtungsrichtlinien anschauen, https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-1-Architecture-01.38.pdf und https://trustedcomputinggroup.org/wp-content/uploads/TCG-TPM-v2.0-Provisioning-Guidance-Published-v1r1.pdf.

TPM 2.0 und Linux sind dann nochmal ein Thema für sich: https://blog.hansenpartnership.com/tpm2-and-linux/.

Nicht zu vergessen sind auch die CVEs mit TPMs, welche es zu beachten gibt: https://www.google.de/search?q=cve+tpm.

Advertisements

Apple iPhone taucht nicht im Windows Explorer auf, kein Zugriff auf Bilder möglich weil MTP fehlt

9 Februar 2018

Auf einem Rechner mit Windows 10 v1709 (64-Bit) schloss man per USB ein iPhone 7 an, es tauchte aber kein Eintrag im Windows Explorer auf. iTunes mit der aktuellen Version war auch installiert, also sollten alle Treiber aktuell verfügbar sein. Das manuelle aktualisieren der Treiber im Gerätemanager wurde auch immer nur mit der Meldung bestätigt, dass man bereits den aktuellen Treiber hat. Was tun?

Die Lösung ist relativ simpel. Man muss nur im Gerätemanager bei den USB-Controllern auf den Eintrag “Apple Mobile Device USB Driver” gehen und die Eigenschaften öffnen. Nun geht man auf das Register Treiber und klickt auf “Treiber aktualisieren”. Im nächsten Dialog klickt man “Auf dem Computer nach Treibern suchen” und dann auf “Aus einer Liste der verfügbaren Treiber auf meinem Computer auswählen”. Es stehen nun zwei Treiber zur Auswahl, der bereits bekannte “Apple Mobile Device USB Driver” und der “MTP-USB-Gerät”-Treiber. Wir wählen den MTP-Treiber. Wird der Treiber installiert, taucht automatisch im Gerätemanager der Eintrag “Tragbare Geräte” auf unter dem dann “Apple iPhone” zu sehen ist.

Nun ist auch das iPhone im Windows Explorer zu finden und nach Freigabe vom iPhone kann man nun problemlos auf den DCIM-Ordner des iPhone zugreifen.

Wichtige Unterschiede zwischen Powershell 5.1 und Powershell Core 6.x bei Invoke-WebRequest und Invoke-RestMethod

3 Februar 2018

Wenn man Invoke-WebRequest oder Invoke-RestMethod unter Powershell Core 6.x benutzt, sollte man im Zweifel nachfolgendes wissen. Die Namen sind die gleichen aber im Hintergrund haben sich einige Dinge geändert.

Ein sehr ausführlicher Artikel beschreibt die Unterschiede der Web-Cmdlets hier: https://get-powershellblog.blogspot.de/2017/11/powershell-core-web-cmdlets-in-depth.html.

So werden z. B. Header Variablen in Powershell Core strenger überprüft, siehe https://get-powershellblog.blogspot.com/2017/11/powershell-core-web-cmdlets-in-depth.html#L08. Um bestehende Scripte möglichst einfach weiterverwenden zu können, könnte man diese Umgebungsvariable setzen:

$PSDefaultParameterValues[‚Invoke-RestMethod:SkipHeaderValidation‘] = $true
$PSDefaultParameterValues[‚Invoke-WebRequest:SkipHeaderValidation‘] = $true

Damit kann man die strikte Header Prüfung abschalten.

Man muss sich auch bewusst sein, dass nun die Rückgabetypen andere sind als bisher. Man sollte also obigen Artikel unter https://get-powershellblog.blogspot.de/2017/11/powershell-core-web-cmdlets-in-depth.html#L09 genauer studieren. Vor allem kann dadurch teilweise die Logik eines Scripts einen ganz anderen Pfad bekommen!!

Nicht weniger wichtig ist das geänderte Verhalten bei Fehlern und Statuscodes: https://get-powershellblog.blogspot.com/2017/11/powershell-core-web-cmdlets-in-depth.html#L13.

Der zweite Artikel in der Blogserie beschreibt welche Features in Powershell Core 6.x im Vergleich zu Windows Powershell 5.1 nicht mehr vorhanden sind. https://get-powershellblog.blogspot.de/2017/12/powershell-core-web-cmdlets-in-depth.html.

Der wichtigste Punkt dabei ist, dass Invoke-WebRequest und Invoke-RestMethod nun keine file:// bzw. ftp://-Protokollle mehr unterstützen!! Nur noch http:// bzw. https:// werden unterstützt. Der zweite wichtige Punkt ist, dass ParsedHTML nicht mehr unterstützt wird, dieser Punkt ist logisch, weil auf den anderen Platformen kein Internet Explorer mit seinem DOM zur Verfügung steht. Dritter Punkt ist die komplette Abwesenheit von New-WebServiceProxy zur Abfrage von SOAP-Endpunkten.

Ein größeres Thema könnten Zertifikate werden, denn aufgrund der Crossplattform-Unterstützung kommen unterschiedliche Bibliotheken zum Einsatz, wo nicht alle Informationen in .Net Core durchgereicht werden und somit Powershell Core nicht zur Verfügung stehen!

OK den Wegfall von SSL 3.0 sollte zu verschmerzen sein, was allerdings blöd ist, ist der Wegfall der Unterstützung von ServicePointManager https://get-powershellblog.blogspot.com/2017/12/powershell-core-web-cmdlets-in-depth.html#L12. Diese Methode hatte früher hier z. B. Anwendung gefunden: https://newyear2006.wordpress.com/2014/07/26/bei-powershell-ssltls-zertifikate-prfung-einfach-ignorieren/. Eine mögliche Lösung ist allerdings Artikel 3 der Serie bei Parameter –SkipCertificateCheck beschrieben.

Der dritte Teil der Blogserie beschreibt Erweiterungen bzw. neue Features die bei Powershell Core in Invoke-WebRequest und Invoke-RestMethod Einzug gehalten haben https://get-powershellblog.blogspot.de/2017/12/powershell-core-web-cmdlets-in-depth_24.html.

Insgesamt haben die beiden Cmdlets 12 neue Parameter erhalten. Die wahrscheinlich wichtigsten sind die Unterstützung für OAuth Authentifizierung und Link-Parameter um REST-Aufrufen über mehrere Ergebnisseiten folgen zu können.

Darüberhinaus wird es mit Powershell Core 6.1.x noch weitere tolle neue Features geben, vor allem bezogen auf Formulare, siehe hier: https://get-powershellblog.blogspot.de/2018/01/powershell-core-61-web-cmdlets-roadmap.html.