Jedną z bolączek wielu administratorów jest konieczność przechowywania ‘wrażliwych’ danych w bezpieczny sposób. Chodzi o wszelkiej maści pliki konfiguracyjne zawierające parametry połączenia, tudzież pliki zawierające login i hasło lokalnego administratora, które stanowią dane wejściowe dla programów typu runas, tworzących nowe procesy w kontekście użytkownika uprzywilejowanego. Jakiś czas temu opisywałem program cpau, który umożliwia przechowywanie danych w postaci zaszyfrowanej i odszyfrowywanie ich dopiero w momencie uruchomienia, co jednak dosyć łatwo udało nam się przechwycić korzystając wyłącznie z debuggera i dzięki czemu bez większych problemów offline’owo mogliśmy odczytać wszystkie dane: login, hasło, etc.
Microsoft rozumie potrzeby administratorów i między innymi dlatego udostępnił w ramach powershella zestaw kilku cmdletów umożliwiający bezpieczne zapisywanie i odczytywanie danych ‘wrażliwych’, którymi nie dzielimy się nawet z żoną :). Dwa z nich to ConvertTo-SecureString oraz ConvertFrom-SecureString. Użycie jest bardzo proste:

W pierwszym poleceniu wczytujemy z klawiatury ciąg znaków, który trafia do zmiennej $secure, która - co widać po drugim poleceniu - jest typu SecureString. W kolejnym zawartość naszej zmiennej $secure zostaje przekonwertowana i zaszyfrowana, po czym trafia do zmiennej $encrypted. Na końcu wypisujemy zawartość zmiennej w postaci łańcucha znaków. Tak przygotowany łańcuch możemy zapisać w pliku, po czym w dowolnym momencie skorzystać z niego, np. korzystając z set-content oraz get-content:

Możemy jeszcze pokusić się o konwersję jawnego tekstu do securestringa, a następnie tego ostatniego przekonwertować do postaci zaszyfrowanej:

Po czym ponownie zapisać to w pliku

Tyle słowem wprowadzenia, nadszedł czas na zajrzenie nieco głębiej.
Rozpoczynamy od ustalenia biblioteki, w której znajduje się definicja ConvertFrom-SecureString oraz ConvertTo-SecureString. Mamy dostępnych kilka metod: począwszy od podejrzenia listy załadowanych modułów powershella w process explorerze, a skończywszy na uruchomieniu kilku poleceń w powershellu:

I już wszystko jasne :). Tak, wiem, powinienem używać najnowszej wersji :)
Skoro mamy już bibliotekę, możemy spróbować dowiedzieć się jaka funkcja odpowiada za szyfrowanie danych. Zaczynamy od załadowania biblioteki snapina do reflectora, dalej przechodzimy do przestrzeni Microsoft.PowerShell.Commands i znajdujemy klasę ConvertFromSecureStringCommand. Słusznie domyślamy się, że za obsługę polecenia odpowiada jedyna metoda klasy, czyli ProcessRecord i dosyć szybko trafiamy na następujący kawałek kodu:

//zrzut z reflectora
        if (base.SecureKey !=null)
        {
            result = SecureStringHelper.Encrypt(this.SecureString, base.SecureKey);
        }
        elseif (base.Key !=null)
        {
            result = SecureStringHelper.Encrypt(this.SecureString, base.Key);
        }
        else
        {
            sendToPipeline = SecureStringHelper.Protect(this.SecureString);
        }

Przyznaję, że nieco z lenistwa niż jakiejś przebiegłości postanawiam, że ustalenie metody, która ma być wywołana przerzucę do WinDbg. A poza tym to jest dobra okazja, żeby zademonstrować zakładanie pułapek na kodzie zarządzanym, więc chyba nikt się nie obrazi ;)
Ładujemy zatem WinDbg, podpinamy się do aktywnego procesu powershella, po czym ładujemy standardowy zestaw sos.dll oraz sosex.dll i ostatecznie ustawiamy pułapkę:

0:003> .loadby sos mscorwks
0:003> .load sosex.dll
0:003> !mbm *!Microsoft.PowerShell.Commands.
ConvertFromSecureStringCommand.ProcessRecord 0
Breakpoint set at Microsoft.PowerShell.Commands.ConvertFromSecureStringCommand.ProcessRecord().
*** WARNING: Unable to verify checksum for C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\Microsoft.PowerShel#\2529703d3e0d2f9fd06cc0230f2bda3f\Microsoft.PowerShell.Security.ni.dll
0:003> !mbl
0 e : *!MICROSOFT.POWERSHELL.COMMANDS.
CONVERTFROMSECURESTRINGCOMMAND.PROCESSRECORD ILOffset=0: pass=1 oneshot=false thread=ANY
    Microsoft.PowerShell.Security!Microsoft.PowerShell.Commands.
ConvertFromSecureStringCommand.ProcessRecord()
        0 e 2242ffd4
0:003> g

Wykonujemy polecenia

Oraz

I po wykonaniu drugiego uaktywnia się nasza pułapka
W tym momencie dodajemy kolejne pułapki:

0:003> !mbm *!Microsoft.PowerShell.SecureStringHelper.Encrypt 0
Breakpoint set at Microsoft.PowerShell.SecureStringHelper.Encrypt(System.Security.SecureString, System.Security.SecureString).
Breakpoint set at Microsoft.PowerShell.SecureStringHelper.Encrypt(System.Security.SecureString, Byte[]).
0:003> !mbm *!Microsoft.PowerShell.SecureStringHelper.Protect 0
Breakpoint set at Microsoft.PowerShell.SecureStringHelper.Protect(System.Security.SecureString).
0:003> g

I puszczamy wykonanie dalej. Po chwili nasza pułapka uaktywnia się, więc znowu lądujemy w debuggerze:

0:003> !clrstack
OS Thread Id: 0x694 (3)
ESP       EIP    
03e1ee70 22430470 Microsoft.PowerShell.SecureStringHelper.Protect(System.Security.SecureString)
03e1eea4 2243007e Microsoft.PowerShell.Commands.ConvertFromSecureStringCommand.ProcessRecord()
03e1eedc 20612648 System.Management.Automation.Cmdlet.DoProcessRecord()
03e1eee4 2064e798 System.Management.Automation.CommandProcessor.ProcessRecord()
03e1ef24 205e8f1d System.Management.Automation.CommandProcessorBase.DoExecute()
03e1ef54 2061c287 System.Management.Automation.Internal.PipelineProcessor.Inject(System.Object, Boolean)

Na początek podejrzyjmy stos. Aha, to była jednak metoda Protect, a nie Encrypt. Przeglądamy pobieżnie reflektorem kod metody Protect i trafiamy szybko na wywołanie:

data = ProtectedData.Protect(userData, null, DataProtectionScope.CurrentUser);

A zaglądając głębiej trafiamy na

if (!CAPI.CryptProtectData(new IntPtr((void*) &cryptoapi_blob2), string.Empty, new IntPtr((void*) &cryptoapi_blob3), IntPtr.Zero, IntPtr.Zero, dwFlags, new IntPtr((void*) &cryptoapi_blob)))

co z kolei dosyć szybko sprowadza nas do wywołania:

[DllImport("crypt32.dll", CharSet=CharSet.Unicode, SetLastError=true)]
internalstaticexternbool CryptProtectData([In] IntPtr pDataIn, [In] string szDataDescr, [In] IntPtr pOptionalEntropy, [In] IntPtr pvReserved, [In] IntPtr pPromptStruct, [In] uint dwFlags, [In, Out] IntPtr pDataBlob);

Ustawiamy zatem kolejną pułapkę, puszczamy wykonanie i patrzymy co będzie dalej:

0:003> !mbm *!System.Security.Cryptography.ProtectedData.Protect
Breakpoint set at System.Security.Cryptography.ProtectedData.Protect(Byte[], Byte[], System.Security.Cryptography.DataProtectionScope).
0:003> g
Breakpoint 4 hit
eax=00000000 ebx=00000000 ecx=01403418 edx=00000000 esi=01403418 edi=03e1ee54
eip=67982e82 esp=03e1ee10 ebp=03e1ee64 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
System_Security_ni+0x62e82:
67982e82 85f6            test    esi,esi
0:003> !clrstack -a
OS Thread Id: 0x694 (3)
ESP       EIP    
03e1ee10 67982e82 System.Security.Cryptography.ProtectedData.Protect(Byte[], Byte[], System.Security.Cryptography.DataProtectionScope)
    PARAMETERS:
        userData = 0x0142e7a4
        optionalEntropy = 0x00000000
        scope = 0x00000000
    LOCALS:
        <no data>
        <no data>
        <no data>
        <no data>
        <no data>
        <no data>
        <no data>
        0x03e1ee10 = 0x00000000

Jak widać, drugi i trzeci parametr to po prostu 0, a pierwszy parametr to tablica bajtów, co szybko możemy udowodnić:

0:003> !do 0x0142e7a4
Name: System.Byte[]
MethodTable: 79333470
EEClass: 790eeb6c
Size: 36(0x24) bytes
Array: Rank 1, Number of elements 24, Type Byte
Element Type: System.Byte
Fields:
None

OK, 24 bajty - brzmi znajomo. Z klawiatury wprowadziłem bowiem 12 znaków…
Robimy zatem zrzut tablicy:

0:003> !dumparray -details 0x0142e7a4
Name: System.Byte[]
MethodTable: 79333470
EEClass: 790eeb6c
Size: 36(0x24) bytes
Array: Rank 1, Number of elements 24, Type Byte
Element Methodtable: 79333520
[0] 0142e7ac
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance       97 m_value
[1] 0142e7ad
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance        0 m_value
[2] 0142e7ae
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance      108 m_value
[3] 0142e7af
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance        0 m_value
[4] 0142e7b0
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance       97 m_value
[5] 0142e7b1
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance        0 m_value
[6] 0142e7b2
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance      109 m_value
[7] 0142e7b3
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance        0 m_value
[8] 0142e7b4
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance       97 m_value
[9] 0142e7b5
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance        0 m_value
[10] 0142e7b6
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance      107 m_value
[11] 0142e7b7
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance        0 m_value
[12] 0142e7b8
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance      111 m_value
[13] 0142e7b9
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance        0 m_value
[14] 0142e7ba
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance      116 m_value
[15] 0142e7bb
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance        0 m_value
[16] 0142e7bc
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance       97 m_value
[17] 0142e7bd
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance        0 m_value
[18] 0142e7be
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance       50 m_value
[19] 0142e7bf
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance        0 m_value
[20] 0142e7c0
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance       53 m_value
[21] 0142e7c1
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance        0 m_value
[22] 0142e7c2
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance       54 m_value
[23] 0142e7c3
    Name: System.Byte
    MethodTable 79333520
    EEClass: 790eebe0
    Size: 12(0xc) bytes
     (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
    Fields:
          MT    Field   Offset                 Type VT     Attr    Value Name
    79333520  4000216        0          System.Byte  1 instance        0 m_value

I wszystko jasne - tablica bajtów zawiera łańcuch unikodowy zawierający wpisane przeze mnie hasło. Tak przygotowana tablica opakowywana jest w strukturę DATA_BLOB, która następnie trafia do funkcji CryptProtectData z biblioteki crypt32.dll.
Czas zatem zajrzeć do dokumentacji. Z pozostałych parametrów ustalamy jeszcze, że skoro optionalEntropy = null, to do funkcji trafia blob z domyślnymi polami, ponadto scope = 0, więc dwFlags = 1. Zaglądając do pliku nagłówkowego szybko ustalamy, że jest to

//Wincrypt.h
#define CRYPTPROTECT_UI_FORBIDDEN        0x1

W uwagach do funkcji CryptProtectData znajdujemy kilka ciekawych informacji:

"Typically, only a user with logon credentials that match those of the user who encrypted the data can decrypt the data. In addition, decryption usually can only be done on the computer where the data was encrypted. However, a user with a roaming profile can decrypt the data from another computer on the network.
If the CRYPTPROTECT_LOCAL_MACHINE flag is set when the data is encrypted, any user on the computer where the encryption was done can decrypt the data.
The function creates a session key to perform the encryption. The session key is derived again when the data is to be decrypted."

Wygląda zatem na to, że nasze dane mogą zostać odszyfrowane wyłącznie przez użytkownika, który je wygenerował i to wyłącznie po zalogowaniu na tej, lub innej należącej do jednej domeny maszynie, o ile dla tego użytkownika jest ustawiony profil mobilny.

DPAPI Internals

Funkcja CryptProtectData oraz bliźniacza CryptUnprotectData stanowią podstawę DPAPI (Data Protection API), czyli usługi ochrony danych opartych o hasła. - Jakie hasło? - ktoś spyta. - Hasło używane podczas logowania do systemu - odpowie dokumentacja. Na jego podstawie wyprowadzane są kolejno: MasterKey, a z niego oraz garści entropii i przypadkowych danych dalej klucze sesyjne. I to za ich pomocą szyfrowane są dane przekazane jawnym tekstem do funkcji CryptProtectData, a zaszyfrowany ciąg bajtów zwracany jest przez funkcję do aplikacji. Tym samym DPAPI zajmuje się wyłącznie szyfrowaniem danych, przechowywanie ich pozostawia jednak samej aplikacji. W konsekwencji zaszyfrowane dane można znaleźć w wielu miejscach systemu: w rejestrze, w katalogach aplikacji, profilu użytkownika, etc, zależnie od wyobraźni i kreatywności programisty :)
Wywołane funkcje DPAPI (z biblioteki crypt32.dll) kontaktują się poprzez RPC z LSA, które to z kolei odwołuje się do właściwych funkcji szyfrujących biblioteki crypt32.dll, jednak już w kontekście samego LSA.
Hasło użytkownika podawane jest raz - podczas logowania i na jego podstawie generowany jest MasterKey, który zmieniany raz na 3 miesiące, (przy kolejnym skorzystaniu DPAPI), lub bezpośrednio po zmianie hasła użytkownika. Dodatkowo, każdy MasterKey zaszyfrowany jest z użyciem hasła użytkownika i dopiero w takiej postaci zostaje zapisany na dysku. Spytacie pewnie: czy tylko ostatni MasterKey jest zapisany na dysku? A ja odpowiem: nie, wszystkie, ponieważ danych zaszyfrowanych z użyciem poprzednich MasterKeys nie da się odszyfrować wyłącznie z użyciem ostatniego MasterKey. Powiem więcej: do odszyfrowania poprzednich MasterKeys potrzebne są hasła użytkownika, które również przechowywane są na dysku w postaci skrótów zaszyfrowanych ostatnim hasłem w pliku CREDHIST.
Fizycznie katalogi, w których przechowywane są MasterKeys oraz plik CREDHIST znajdują się w:

MasterKeys: %APPDATA%\Microsoft\Protect\{UserSID}
CREDHIST: %APPDATA%\Microsoft\Protect\

Każdy MasterKey ma swój unikalny GUID i dla usprawnienia całego procesu plik zawierający zaszyfrowany MasterKey ma nazwę taką, jaki ma GUID. Dodatkowo, w katalogu zawierającym MasterKeys jest plik Preferred zawierający GUID ostatniego MasterKey i to właśnie on wybierany jest do szyfrowania danych.
W przypadku danych, które mają być dostępne dla wszystkich użytkowników systemu, używane są klucze systemowe, które można znaleźć w katalogu %SystemRoot%\System32\Microsoft\Protect\S-1-5-18
Konto systemu nie ma hasła, wobec czego nie ma konieczności przechowywania pliku CREDHIST.
Z tego krótkiego opisu wynika, że każda aplikacja uruchamiana w kontekście zalogowanego użytkownika będzie miała dostęp do wszystkich danych. Żeby się przed tym ustrzec, aplikacja może przekazać do CryptProtectData własny kluczyk (entropia), bez którego nie będzie można danych odszyfrować. Jak widzieliśmy jednak wcześniej, nasz PowerShell jednak z tej możliwości nie korzysta (optionalEntropy = 0x00000000 w parametrach funkcji System.Security.Cryptography.ProtectedData.Protect), co umożliwia każdej aplikacji uruchomionej przez tego samego użytkownika na odszyfrowanie danych. Sprawdźmy to!
W tym celu skorzystajmy z kodu (zamieszczam pełen, ponieważ nie jest aż taki długi, a dzięki temu każdy będzie mógł z niego skorzystać od razu):

using System;
using System.Globalization;
using System.IO;
using System.Text;
using System.Security.Cryptography;

namespace pl.net.zine.Articles.DPAPI
{
  publicclass SecureStringPSDecrypter
  {
    publicstaticvoid Main(string[] args)
    {
      if (args.Length > 0)
      {
        byte[] encryptedData = BlobFileUtils.ReadBlobFromTextFile(args[0]);
        byte[] originalData = ProtectedData.Unprotect(encryptedData, null, DataProtectionScope.CurrentUser);
        Console.WriteLine("The original data is:");
        Console.WriteLine(BlobFileUtils.StringFromByteArray(originalData));
      }
      else
        Console.WriteLine("Usage: {0} encrypted_file.txt", System.Diagnostics.Process.GetCurrentProcess().ProcessName);
    }
  }

  publicclass BlobFileUtils
  {
    publicstaticstring StringFromByteArray(byte[] arr)
    {
      int len = arr.Length;
      StringBuilder sb =new StringBuilder();
      for(int i = 0; i < len; i+=2)
      {
        sb.Append((char)arr[i]);
      }
      return sb.ToString();
    }

    publicstaticbyte[] ReadBlobFromTextFile(string fileName)
    {
      return ConvertToByteArr(ReadSecureStringEncrypted(fileName));
    }

    privatestaticbyte[] ConvertToByteArr(string text)
    {
      int num = text.Length / 2;
      byte[] byteArr =newbyte[num];
      if (text.Length > 0)
      {
        for (int i = 0; i < num; i++)
        {
          byteArr[i] =byte.Parse(text.Substring(2 * i, 2), NumberStyles.AllowHexSpecifier, CultureInfo.InvariantCulture);
        }
      }
      return byteArr;
    }

    privatestaticstring ReadSecureStringEncrypted(string file)
    {
      string text ="";
      using (TextReader reader =new StreamReader(file))
      {
        text = reader.ReadToEnd();
      }
      return text;
    }
   }
}

Kompilujemy i uruchamiamy dla naszych przykładowych danych:

Cała magia sprowadza się do linijki:

byte[] originalData = ProtectedData.Unprotect(encryptedData, null, DataProtectionScope.CurrentUser);

w której następuje właściwe odszyfrowanie danych, a zgodnie z naszymi wcześniejszymi obserwacjami drugi parametr (optionalEntropy) wystarczyło ustawić na null.

Proste? :)

Tekst zrobił się przepotwornie długi, więc w tym miejscu dokonuję cięcia. Dalsza część poświęcona głębszemu zajrzeniu do DPAPI pojawi się w następnym wpisie, gdzie spróbuję dodatkowo odpowiedzieć na pytanie 'czy jest możliwe offline’owe odszyfrowanie danych zapisanych przez DPAPI?' i jak to się ma do EFS-a, haseł Internet Explorera, etc.

Zainteresowani ciągiem dalszym?

Kolejna część naszych zabaw z DPAPI i jeszcze głębsze wejrzenie w mechanizmy nim rządzące.

W poprzednim odcinku znęcaliśmy się nieco nad PowerShellem, z którego pomocą wygenerowaliśmy kilka plików z zaszyfrowanymi danymi. Celowo poprzednio zamieściłem na początku tekstu zrzuty dwóch moich danych, dorzućmy do tej potrawy dodatkowo zaszyfrowany ciąg z przykładu ze strony MSDN i zamieszajmy nieco :)

Przypomnę zatem zaszyfrowane dane z poprzedniego wpisu:
1.
01000000d08c9ddf0115d1118c7a00c04fc297eb010000008727d6117f2b0c429d84f2b9f7e9ea35
0000000002000000000003660000a8000000100000009403327f1497e1a4266ca7d45f84266a0000
000004800000a000000010000000ed0b8a5247be59846e80ca735a1a3f9720000000a5025c6e7ee4
cad037fcd99a5cbbe4aef20d54e685352fa67c1deec0999779c7140000002f96e55035c6760aba6f
4bb9aeffc52616cb300c

2.
01000000d08c9ddf0115d1118c7a00c04fc297eb010000008727d6117f2b0c429d84f2b9f7e9ea35
0000000002000000000003660000a80000001000000037f547b0feab4a12ab792d809a63fd0a0000
000004800000a000000010000000426ad5282726129ddce3675e82c68ca018000000b00bf7525cca
296dc3753d4aaaf867deec089bcbc94c73c21400000091011d6139ce2150b304f0cabaa7dc8b21fb
65d3

3.
01000000d08c9ddf0115d1118c7a00c04fc297eb010000001a114d45b8dd3f4aa11ad7c0abdae980
0000000002000000000003660000a8000000100000005df63cea84bfb7d70bd6842e7efa79820000
000004800000a000000010000000f10cd0f4a99a8d5814d94e0687d7430b100000008bf11f196015
8405b2779613e9352c6d14000000e6b7bf46a9d485ff211b9b2a2df3bd6eb67aae41

Po chwili bliższego przyglądania się, możemy powyższe ciągi podzielić na kilka grup:

A. pierwsze 48 znaków jest identyczne w przypadku wszystkich trzech zrzutów:
01000000d08c9ddf0115d1118c7a00c04fc297eb01000000

B. następne 32 znaki są identyczne w przypadku moich zrzutów i różne od przykładowych z MSDN.
8727d6117f2b0c429d84f2b9f7e9ea35

C. kolejne 44 znaki są identyczne w przypadku wszystkich 3 zrzutów
0000000002000000000003660000a800000010000000

D. dalej kolejne 32 znaki różne we wszystkich 3 przypadkach.
9403327f1497e1a4266ca7d45f84266a

E. następne 32 znaki są identyczne we wszystkich 3 zrzutach
0000000004800000a000000010000000

F. i potem następuje dosyć długi ciąg różnej długości dla wszystkich 3 zrzutów.
ed0b8a5247be59846e80ca735a1a3f9720000000a5025c6e7ee4cad037fcd99a5cbbe4aef20d54e6
85352fa67c1deec0999779c7140000002f96e55035c6760aba6f4bb9aeffc52616cb300c

Spróbujmy rzucić nieco światła na powyższe dane.  Zacznijmy nasze poszukiwania jakichś wskazówek od zajrzenia do katalogów zawierających klucze MasterKey. W moim przypadku mogę tam znaleźć pliki o następujących nazwach:

Plik Prefered zawiera ciąg bajtów:
87 27 D6 11 7F 2B 0C 42 9D 84 F2 B9 F7 E9 EA 35 C0 BD E3 CB 49 0B CC 01
który zgodnie z tym, o czym pisałem w poprzednim odcinku, zawiera GUID klucza Master, którego ma aktualnie używać DPAPI + dodatkowe informacje.

I tak, pierwsze 16 bajtów to ciąg:
87 27 D6 117F 2B0C 429D 84F2 B9 F7 E9 EA 35
który odpowiada GUIDowi:
11d62787-2b7f-420c-9d84-f2b9f7e9ea35

W tym momencie bez trudu stwierdzamy, który plik z katalogu kluczy zawiera preferowany MasterKey. Bez większych problemów ustalamy również, że blok B z naszego zaszyfrowanego ciągu to po prostu GUID MasterKey użytego do zaszyfrowania danych.

Dochodzimy do miejsca, w którym głos należy oddać dwóm panom: Elie Bursztein oraz Jean-Michel Picod i ich prezentacji o internalsach DPAPI, która została przedstawiona w ubiegłym roku na konferencji BlackHat DC 2010 , a do której materiały dostępne są na stronie www.dpapick.com.
Znajdziemy tam między innymi względnie kompletny opis bloba, a co za tym idzie również naszego bloku A.

I tak, nasz blok A po podzieleniu na części to:

01000000 - liczba użytych dostawców usług kryptograficznych (crypto provider), w naszym i praktycznie każdym przypadku - 1;

d08c9ddf0115d1118c7a00c04fc297eb - GUIDy użytych crypto providers, w naszym przypadku jest to df9d8cd0-1501-11d1-8c7a-00c04fc297eb i odpowiada bibliotece psbase.dll (zgodnie z opisem, znajdziemy tę informację w kluczu HKLM\Software\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb);

01000000 - liczba kluczy MasterKeys użytych do szyfrowania.

Cała struktura bloba przedstawia się następująco [ze wspomnianej wyżej pracy E.B. i J-M.P]:

struct dpapi_blob_t {
DWORD cbProviders; // Num of crypto providers
GUID *arrProviders; // Crypto Providers GUIDs
DWORD cbKeys;
GUID *arrKeys; // Keys GUIDs (tu zaczyna się nasz blok B)
DWORD ppszDataDescrSize; // WARNING: in bytes
WCHAR *ppszDataDescr;
DWORD idCipherAlgo;
DWORD idHashAlgo;
BYTE *pbSalt; //Salt
BYTE *pbCipher; //Encrypted data
BYTE *pbHMAC; //HMAC
};

Ale co jest takiego wyjątkowego w ciągu z bloku A? Mogliśmy już to przyuważyć porównując dane z przykładu MSDN oraz mojego, choć jeszcze nie mieliśmy tej pewności. Odpowiedź jest prosta i po powyższych wywodach powinniśmy już ją znać: otóż jest to 'odcisk buciora' DPAPI, znak rozpoznawalny praktycznie zawsze i wszędzie. Jeśli kiedykolwiek będziecie czesali dysk, rejestr, pamięć, cokolwiek, w poszukiwaniu danych zaszyfrowanych z użyciem DPAPI, to wystarczy, że znajdziecie ten ciąg, a reszta będzie już tylko formalnością. :)

"Ale jaka ‘reszta’?" - ktoś spyta.
"Offline’owe odszyfrowanie tych danych" - odpowiedzą zgodnie panowie Bursztein i Picod.
"Zaraz, zaraz - przecież pisałeś, że dane dostępne są wyłącznie dla zalogowanego użytkownika, do tego LSA i… w ogóle to niemożliwe!" - słyszę kolejny oburzony głos.
Wszystko prawda. A przynajmniej w dokumentacji na stronach MSDN. Ale nie dla panów Picod i Bursztein :)
Na stronie dpapick.com możemy znaleźć przykładową aplikację wykorzystującą przygotowaną przez autorów bibliotekę libDPAPIck.dll pozwalającą na offline’owy dostęp do danych zaszyfrowanych z użyciem DPAPI. Wszystko, czego potrzebujemy, to:
- zestaw plików MasterKeys z katalogu kluczy użytkownika, w imieniu którego dane zostały zaszyfrowane;
- zaszyfrowany ciąg danych;
- tekstowe hasło użytkownika.

"Eee" - ktoś się skrzywi - "Hasło?"
Tak, cudów nie ma. Do odszyfrowania klucza MasterKey musi zostać wygenerowany Pre-Key, który wyprowadzany jest właśnie z hasła użytkownika, obejść się tego nie da. Oczywiście możemy zajrzeć do bazy sam i spróbować znaleźć hasło, dla którego mamy skrót, ale jest to pracochłonne i niekoniecznie najprostsze.

Są jednak sytuacje, kiedy znamy hasło i chcielibyśmy dostać się bez podnoszenia systemu do zaszyfrowanych danych i ta biblioteka nam to umożliwia. Autorzy podają jako przykład dostęp do plików szyfrowanych z użyciem EFS, haseł Internet Explorera i innych aplikacji z poziomu Wine’a, czyli ogólnie wsparcie interoperacyjności, lecz nie tylko. Tak na marginesie dodam, że przechowywaniem haseł z użyciem Credential Managera (opartym rzecz jasna na DPAPI) zajmiemy się w jednym z kolejnych wpisów.
Ja oczywiście podam jako przykład aplikację, która odczytuje offline’owo hasła zapisane do pliku w PowerShellu, naturalnie z wykorzystaniem biblioteki libDPAPIck.dll. Nie będę przedstawiał całego kodu źródłowego, jednak w oryginalnym przykładzie zabrakło paru drobiazgów, które mogą uniemożliwić nam odszyfrowanie danych, i nimi się teraz zajmiemy.

Do deszyfrowania danych skorzystamy z wyeksportowanej funkcji:

[DllImport("libDPAPIck.dll", CharSet = CharSet.Auto)]
publicstaticexternbool DPAPIBlobDecrypt(StringBuilder blobPath, ref DATA_BLOB blobEntropy, ref DATA_BLOB blobStrongPassword, ref DATA_BLOB blobMasterkey, ref DATA_BLOB blobResult);

Po pierwsze - do oryginału (tu uwaga: kodu źródłowego nie ma, ale wystarczy użyć reflectora, lub innego dezasemblera .net i możemy to i owo dodać) należy dodać funkcję odczytującą GUID MasterKey użytego do zaszyfrowania danych, co na podstawie powyższego opisu sprowadza się mniej-więcej do czegoś takiego:

privatestring retrieveMasterGuidFromBlob(byte[] blob)
{
  int startGuidPos = 24; // początek bloku B
  int guidLen = 16; // 16 bajtów na guid
  byte[] byteGuid =newbyte[guidLen];
  Array.Copy(blob, startGuidPos, byteGuid, 0, guidLen);
  returnnew Guid(byteGuid).ToString();
}

Tak odczytany Master-Guid należy wykorzystać w funkcji deszyfrującej MasterKey, gdzie w oryginale wykorzystywany jest pierwszy Master z listy, zamiast tego użytego do zaszyfrowania danych. Pozostawiam to jako ćwiczenie.
Nasze dane zapisane są w postaci tekstowej, należy więc dokonać konwersji ich na ciąg bajtów, co pozostawiam jako proste ćwiczenie. Oczywiście w przypadku danych z innych aplikacji taka konwersja nie musi być konieczna, więc myśląc ‘przyszłościowo’ należałoby to uwzględnić.
W samej funkcji deszyfrującej blob należy jeszcze pamiętać o tym, że zaszyfrowany przez PowerShell ciąg znaków był unikodowy, a nie ASCII i to już właściwie daje nam możliwość uruchomienia aplikacji na dowolnym komputerze, na który skopiowaliśmy katalog z kluczami oraz zaszyfrowany plik:

Pierwszym parametrem jest nazwa katalogu zawierającego MasterKeys, drugim - hasło użytkownika, a jako trzeci podaję nazwę pliku txt zawierającego zaszyfrowany ciąg. I gotowe! :)

Jakiś czas temu zgłosiłem Eliemu i Jean-Michelowi drobne uwagi (w tym powyższe) i następna wersja, planowana na kolejną edycję konferencji BlackHat miała je zawierać. Dodatkowo (co wiem nieoficjalnie z wymiany mailowej z Elie i Jean-Michelem) DPAPIck prawdopodobnie będzie wspierać Windows 7 i środowisko domenowe, a do pobrania będzie kilka przykładowych aplikacji do odszyfrowywania danych konkretnych aplikacji.

Całość badań nad DPAPI wygląda bardzo obiecująco, więc warto co jakiś czas sprawdzać postęp prac nad biblioteką.

Przyznaję, że początkowo tekst miał wyglądać nieco inaczej, jednak ostatecznie stwierdziłem, że pewne rzeczy - jak np. odniesienia do EFSa, czy Credential Managera zostawię na inne wpisy. Zrezygnowałem również z publikacji większych kawałków kodu - pomimo tego, że dyskutowałem z Elie i Jean-Michelem o kodzie, to jednak nigdy nie spytałem wprost, czy mogę fragmenty swojej przeróbki opublikować. Tak więc - należy uzbroić się w cierpliwość - już za kilka tygodni kolejna edycja BlackHata, a tym samym publikacja poprawionej wersji DPAPIck :)

Przygód z EFS ciąg dalszy. Dziś docieramy do obszarów, które wykorzystywane są również w innych miejscach systemu, dlatego niezbędny jest osobny tekst i odpowiedni podtytuł. Jedziemy!

Certyfikat

W poprzedniej części dotarliśmy do miejsca, w którym powiązaliśmy zaszyfrowany FEK z certyfikatem użytkownika. Zajrzyjmy do menadżera certyfikatów (tylko informacyjnie, bo przecież w trybie offline nie będziemy mieli już takiego komfortu!).


Mając w pamięci certyfikat widziany z poziomu certmgr, zaglądamy szybko do pliku certyfikatu, który - jak przypomnę - znajduje się w profilu użytkownika: %APPDATA%\Microsoft\SystemCertificates\My\Certificates\ i ma nazwę związaną z thumbprintem certyfikatu, czyli skrótem SHA1: EFF5EDAB8123D06B6EFEA7D87716B03F9C8F48CD.


Plik certyfikatu z Rys 2. zawiera wyłącznie część publiczną klucza, którego fragment widzimy na zrzucie z ekranu (Rys 1.) i dla ułatwienia zaznaczyłem na pomarańczowo w Rys 2. Najistotniejsza część, czyli sam klucz publiczny to 256 bajtów zaznaczone na czerwono. Dodatkowo, zaznaczony na zielono obszar to kompletny plik certyfikatu (w formacie ASN), który uzyskalibyśmy klikając ‘Copy to file’ w oknie z Rys 1 i wybierając opcję ‘No, don’t export private key’ oraz wskazując format ‘DER encoded binary X.509 (.CER)’. Wyodrębnijmy zatem tę część do osobnego pliku i przepuśćmy przez systemowy certutil:

W tym momencie mamy już dużo szczegółów dotyczących pliku certyfikatu: wiemy, że użyte zostało RSA, certyfikat przeznaczony jest do użycia w systemie szyfrowania plików, znamy daty ważności pliku, etc., jednak najważniejsza informacja kryje się na Rys 2. pod niebieskim zaznaczeniem. Jest to Key container zapisany w UTF-16LE, który w zrzucie z certutil zaprezentuje nam się następująco:

i pozwala nam na jednoznaczne zidentyfikowanie pliku zawierającego klucz prywatny tego certyfikatu. W powyższym zrzucie narzędzia certutil występuje jeszcze Unique container name, który jest jeszcze ciekawszy. Zawiera on wprost nazwę pliku z kluczem prywatnym, jednak sposób otrzymania Unique container name jest dla mnie zagadką i w trybie offline nie jestem w stanie jej odtworzyć. To, co udało mi się zauważyć, to to, że nazwa składa się z dwóch części: <dynamic_guid>.<machine_guid>, przy czym <machine_guid> zapisany jest w rejestrze w kluczu HKLM\Software\Microsoft\Cryptography we wpisie MachineGuid, natomiast pochodzenia <dynamic_guid> nie udało mi się ustalić. Mogę tylko przypuszczać, że może to być jakiś skrót fragmentu, bądź całości certyfikatu, ale większych testów i poszukiwań nie przeprowadziłem. Jeśli ktoś wie coś więcej, to zapraszam do podzielenia się swoją wiedzą :)
Mając Key Container, pubkey oraz datę utworzenia pliku certyfikatu jestem w stanie dosyć szybko odnaleźć drugą, brakującą część układanki.

Klucze RSA

Użycie RSA wiąże się z utworzeniem pliku zawierającego wszystkie parametry RSA. Zapisywany on jest w profilu użytkownika, a dokładniej %APPDATA%\Microsoft\Crypto\RSA\{SID}. W omawianym przeze mnie przypadku będzie to: C:\Users\Admin\AppData\Roaming\Microsoft\Crypto\RSA\S-1-5-21-580747136-2243477503-2994681153-1000.
Już pierwszy rzut oka na zawartość tego katalogu pozwala na zorientowanie się, że wszystkie nazwy mają podobny schemat, o którym kilka zdań wyżej pisałem nieco więcej. Pamiętajmy, że RSA używane jest w różnych miejscach systemu i pliki z kluczami nie muszą być powiązane z żadnym certyfikatem, bo przecież to tylko jedno z wielu możliwych użyć RSA. Kolejna rzecz - z moich obserwacji wynika, że system nie mając informacji o tym, że klucz RSA nie jest już do niczego przydatny, nie może usunąć plików i pozostawia je tam nietknięte. Przestrzegam jednak przed ‘porządkami’ w kluczach, bo może się okazać, że gdzieś jednak klucz jest jeszcze używany i wtedy może być troszkę gorzej ;)
Mając jednak same: pubkey, key container oraz datę pliku (z pliku certyfikatu) musimy przeczesać wszystkie pliki w poszukiwaniu tego, który nas interesuje. I jeśli tylko odpowiedni plik istnieje, to go znajdziemy. Poniżej wynik naszych poszukiwań.


Plik podzielony jest z grubsza na 4 główne części:
[] nagłówek - w którym znajdziemy podstawowe informacje dotyczące pozostałych elementów oraz wyróżniony na [] czerwono key container, który widzieliśmy wcześniej w pliku certyfikatu (tu mamy kodowanie ASCII);
[] rsaheader - z częścią publiczną klucza oraz jednym z parametrów algorytmu (pubexp = 65537, co jest najczęściej używaną wartością);
[] blob DPAPI zawierający klucz prywatny RSA;
[] blob DPAPI zawierajacy dodatkowe dane służące do odszyfrowania klucza prywatnego.

Jako ciekawe i bardzo pouczające zadanie pozostawiam odnalezienie klucza publicznego w sekcji pomarańczowej :)

Na Rys 4 możemy znaleźć więcej szczegółów opisanych wyżej pierwszych dwóch składowych wraz z wyróżnioną nazwą key containera.


Dziwić może nadmiarowy rozmiar tablicy zawierającej klucz publiczny - w końcu powinien wynosić 256, a nie 264 bajtów. Rzut oka na zawartość tablicy i wszystko jasne - wystarczy obciąć ostatnie 8 zerowych bajtów i mamy kluczyk (obcinamy tak naprawdę do bitlength / 8).

Wszystko fajnie, ale gdzie jest klucz prywatny? Przecież bez niego nie odszyfrujemy efs-owego FEKa i nie będziemy w stanie dostać się do zawartości zaszyfrowanego pliku! Odpowiedzi należy szukać w dwóch tajemniczych polach: rsapk oraz rsaFlags, które zapisane są z użyciem tej samej struktury: DPAPIBlob. Czas na bardzo głębokie zanurzenie!

DPAPI

Struktury danych oraz algorytmy użyte w DPAPI przez długi czas stanowiły zagadkę i w zasadzie dopiero prace przy DPAPIck doprowadziły do względnego uporządkowania dostępnej wiedzy. Niemal 4 lata temu w swojej blotce o zabezpieczeniach związanych z SecureString  wspominałem już o DPAPI (a także o efs), jednak nie wchodziłem bardzo głęboko w szczegóły. Prawdę powiedziawszy od tamtego czasu niewiele się w tej materii zmieniło, temat nadal jest słabo omawiany i poza DPAPIck w zasadzie brakuje narzędzi pozwalających na eksplorację. Jak widać, nawet tak długi czas pozwala na zupełnie świeże jego przedstawienie: po polsku nie znalazłem nic interesującego, więc albo temat nie jest ciekawy, albo nikt, kto rozpoznał go w całości nie podjął się szerszej prezentacji. Czas tę lukę wypełnić, zapraszam w otchłań podstawowych mechanizmów systemowych związanych z zabezpieczaniem wrażliwych danych użytkownika.

Podstawowym założeniem DPAPI jest umożliwienie użytkownikowi przechowywanie jego wrażliwych danych (np. danych logowania do różnych systemów, kluczy szyfrujących, etc.) w sposób bezpieczny. Przy czym ‘sposób bezpieczny’ należy rozumieć jako taki, który zapewnia, iż odzyskanie oryginalnych danych jest bardzo trudne, lub wręcz niemożliwe, bez znajomości pewnych faktów. Informacją, na której opiera się bezpieczeństwo całego systemu jest hasło użytkownika, a precyzyjniej skrót hasła (SHA1 - najczęściej; czasem MD4). Na podstawie skrótu hasła generowany jest zestaw kluczy (masterkeys), które służą do odszyfrowywania blobów DPAPI. Aby zabawę nieco urozmaicić pomyślmy o tym, co się dzieje, gdy użytkownik zmieni hasło. W takim momencie bieżący skrót hasła  nie może zostać wykorzystany do odszyfrowywania masterkeys, więc system musi skądś ten skrót wziąć. Miejscem tym jest plik CREDHIST, w którym zapisane są wszystkie skróty haseł użytkownika, które były w użyciu w momencie korzystania z DPAPI.
Po tym krótkim wstępie wróćmy do naszego certyfikatu, a dokładniej pliku zawierającego klucz prywatny RSA. Dwie ostatnie składowe pliku to bloby DPAPI, i dla poprawy czytelności skupimy się na drugim z nich. Struktury są bowiem identyczne, jednak długość pierwszego jest znacznie większa od drugiego, więc zajmowanie się dłuższym na pewno nie poprawi zrozumienia, a wręcz przeciwnie. Najciekawsze pola tego bloba znajdziemy na Rys 5 (kolor poprzedzającego bloba zmieniłem na czarny).


Bardziej szczegółowy opis znajdziemy na Rys 6.


W tym momencie najważniejsze pole to mkguid, które w przypadku obu blobów jest identyczne:
f36aeda2-00fc-40d3-bac6-41866e959715. Zanim go omówimy dokładniej, rzućmy okiem na pozostałe wyróżnione pola bloba:
[] provider - Guid providera, który został użyty przez DPAPI do szyfrowania. Występuje w zasadzie we wszystkich blobach DPAPI i tym samym stanowi jego wyróżnik, którego można użyć w poszukiwaniu blobów rozsianych po dysku, rejestrze, etc.;
[] cipherAlgo (0x6610) - liczba określająca użyty algorytm symetryczny;
[] hashAlgo (0x800E) - liczba określająca użyty algorytm wyliczania skrótu;
[] salt - tablica bajtów zawierająca sól użytą podczas wyliczania klucza deszyfrującego;
[] hmac - dla porównania tablica bajtów gwarantująca, że nikt nie gmerał przy całym blobie :)
[] cipherText - tablica bajtów zawierająca zaszyfrowane dane;
[] sign - tablica bajtów zawierająca blob podpisany hmacem do potwierdzenia integralności bloba.

Można się w tym momencie zastanawiać, dlaczego w kluczu RSA znajdują się dwa bloby DPAPI, ale odpowiedź na to pytanie przyjdzie później, teraz pomyślmy skąd wziąć klucz deszyfrujący dla bloba.

Ścieżka prowadzi poprzez tajemniczy mkguid. Czas wejść w trzewia DPAPI.

Masterkey

Wszystkie pliki związane z DPAPI znajdują się w profilu użytkownika, w katalogu %APPDATA%\Microsoft\Protect (Rys 7)


Omawiany guid to po prostu nazwa pliku zawierającego masterkey, który znajduje się w podkatalogu %APPDATA%\Microsoft\Protect\{SID}, gdzie {SID} to oczywiście sid użytkownika (Rys 8).


Zaznaczony plik to interesujący nas masterkey, który zawiera klucz deszyfrujący bloba DPAPI. Jesteśmy już bardzo blisko rozwiązania, niemal czujemy zapach klucza :) Zobaczmy zatem, jak wygląda plik masterkey.


Już na pierwszy rzut oka możemy odnaleźć masterkey guid (mkguid), który zapisany jest w postaci łańcucha znaków w kodowaniu UTF-16LE. Pozostałe wyróżnione elementy wymagają dodatkowego opisu struktury, który znajdziemy na Rys 10.


Z najciekawszych pól na szczególną uwagę zasługują pola struktury masterkey:
[] iv - wektor inicjalizacyjny wykorzystany do odszyfrowania bloba zapisanego jako [] cipherText.
[] hashAlgo - ponownie liczba wskazująca na użyty algorytm haszujący;
[] cipherAlgo - i tu wracamy do liczby wsazującej na użyty algorytm symetryczny;
[] rounds - liczba określająca liczbę rund użyta przy obliczeniach skrótu z użyciem funkcji pbkdf2.

Jednak najważniejszy element kryje się na samym końcu: guid, który prowadzi nas do kolejnej zagadki: pliku Credhist. Mamy bowiem niemal wszystkie elementy układanki związanej z plikiem masterkey, brakuje nam tylko jednego: klucza deszyfrującego. Bez niego nie jesteśmy w stanie odszyfrować zawartości ciągu cipherText, a więc brniemy dalej.
Zanim jednak to uczynimy, krótka wzmianka o pliku Prefered. DPAPI zapisuje w nim guid związany z plikiem masterkey, który jest 'preferowany', czyli powinien zostać użyty, a także datę, kiedy preferowany plik master powinien zostać zastąpiony kolejnym (Rys Prefered 1, Prefered 2)



Jak widać, datą graniczną dla bieżącego pliku jest 22 kwietnia. Rzucamy okiem na Rys 8. i okazuje się, że DPAPI zamierza wymieniać plik master na nowy po 3 miesiącach od utworzenia poprzedniego. Czego brakuje w pliku Prefered? Jakiegoś HMACa - wystarczy ustawić odpowiednio odległy czas i możemy jechać na jednym pliku master tak długo, jak będziemy chcieli.

Credhist

Już we wstępie do DPAPI napisałem, że plik Credhist zawiera skróty haseł użytkownika, które zostały użyte do zaszyfrowania masterkeys. Myliłby się jednak ten, który sądzi, iż są one zapisane tam w postaci jawnej i tylko czekają na wyciągnięcie. O nie, co to, to nie! Zresztą sami zobaczmy.


Hmm… długi ten zrzut jak na wpis na blogu. Ale przynajmniej wszystko widać, jak na dłoni! Plik podzielony jest z grubsza na nagłówek i tablicę elementów typu CredHistEntry, które starałem się pokolorwać w różne odcienie przechodzące między zielenią, a jakimś fioletem. Ostatni, a w istocie pierwszy wpis tej listy, widoczny na dole Rys 11 powinien być najbardziej zielony ze wszystkich, jednak zdjąłem z niego ten kolor i wyróżniłem różnymi kolorami najciekawsze elementy struktury, szczegóły na Rys 12.



- hashAlgo, rounds, cipherAlgo, iv - opisywane wcześniej, stanowią parametry funkcji kryptograficznych wyprowadzających klucze oraz biorące udział w deszyfrowaniu ciągu encrypted,
- guid: tu z łatwością odnajdujemy guid zapisany w pliku masterkey (zaznaczony ramką). Zauważmy, że guidy innych wpisów CredHistEntry mają inne guidy (dla porównania rozwinąłem także 3 element listy).

Wszystko fajnie, ale ciągle jeszcze nie wiemy jak wyłuskać interesujący nas klucz deszyfrujący dla naszego pliku masterkey.
W tym momencie przypomina mi się fragment filmu ‘Skarb narodów’, w którym ojciec głównego bohatera stwierdza, iż "a to cię zaprowadzi do kolejnej wskazówki. I zawsze będziesz znajdywał tylko wskazówki.". Mamy bowiem:
- zaszyfrowany fek, do odszyfrowania którego szukamy klucza w
- zaszyfrowanym blobie dpapi w pliku zawierającym prywatny klucz rsa, do odszyfrowania którego potrzebujemy klucza z
- zaszyfrowanego masterkey, do odszfrowania którego potrzebny jest klucz zapisany w
- zaszyfrowanym wpisie w pliku Credhist, do odszyfrowania którego potrzebny jest
- skrót hasła użytkownika.

Ha! :)
Hola, hola! Czyż nie zaskoczyło nikogo to, że pierwszy wpis w pliku Credhist znajduje się na końcu pliku? Okazuje się bowiem, że przy pierwszym dostępie do DPAPI po zmianie hasła przez użytkownika następuje dopisanie bieżącego skrótu na końcu pliku, a poprzedni wpis zostaje zaszyfrowany z użyciem bieżącego skrótu. Aby zatem dostać się do n-tego wpisu, musimy wykonać n-1 operacji odszyfrowania kolejnych skrótów, biorąc wyliczony poprzedni jako klucz do kolejnego. Pierwszym, biorącym udział w całej operacji jest oczywiście bieżący skrót użytkownika.
Wydawałoby się, że plik Credhist jest zatem dosyć dobrym źródłem skrótów haseł i można pokusić się o łamanie ich. Tu okazuje się jednak, że nie ma to większego sensu, albowiem skróty haseł odszyfrowane są następująco:
- na podstawie skrótu SHA1 (rzadziej MD4) hasła użytkownika oraz jego SIDu (zakończonego \0) wyliczany jest HMAC-SHA1 (encKey);
- tak wyliczony encKey trafia do funkcji pbkdf2 wraz z pozostałymi parametrami, w naszym przypadku:
cipherKey = pbkdf2(hashAlgo = 0x800e (SHA512), encryptionKey = encKey, iv = iv(16 bajtów widocznych na Rys 11), rounds = 17400)
- tak wyznaczony klucz (cipherKey) trafia do algorytmu symetrycznego (w naszym przypadku AES-256-CBC), przy czym początkowe 32 bajty stanowią klucz, a pozostałe 16 - wektor inicjujący i po 3 przebiegach uzyskujemy 48 bajtów odszyfrowanych danych.

W ramach odszyfrowanych danych dostajemy 20 bajtów skrótu SHA-1 oraz 16 bajtów skrótu MD4 (NTHash). Poniżej wyniki z badanego przez nas pliku:
Jak widać, zmieniałem co najmniej kilkanaście razy hasło, przy czym wygląda na to, że używałem na zmianę dwóch :) Z użyciem prostego kalkulatora (który wylicza także skrócik MSDCC2) mogę porównać:

Back to masterkey

Mając skróty dla wpisu o interesującym nas guidzie możemy wrócić do pliku masterkey, gdzie wykonujemy kroki podobne do tych, które wykonywaliśmy przed chwilą:
- rozpoczynamy od wyliczenia skrótu HMAC-SHA1 (encKey) na podstawie skrótu hasła (wyciągniętego przed chwilą) oraz SIDa zakończonego "\0";
- tak wyliczony encKey trafia do funkcji pbkdf2 wraz z pozostałymi parametrami, w naszym przypadku:
cipherKey = pbkdf2(hashAlgo = 0x800e (SHA512), encryptionKey = encKey, iv = iv(16 bajtów widocznych na Rys 10), rounds = 17400)
- tak wyznaczony klucz (cipherKey) trafia do algorytmu symetrycznego (w naszym przypadku AES-256-CBC), przy czym:
(i) pierwsze 16 bajtów to salt, który za chwilkę użyjemy do wyliczenia hmaca;
(ii) kolejne 512(z bitowej długości hasza) / 8 = 64 bajty to hmac, z którym za chwilę porównamy nasz;
(iii) ostatnie 64 bajty wyniku zawierają odszyfrowany klucz masterkey_decrypted.
Do wyliczenia "hmaca" bierzemy encKey, salt, masterkey_decrypted i stosujemy funkcję skrótu hashAlgo (najpierw na encKey + salt), później na wynik tego + masterkey_decrypted.

Back to rsafile

Możemy teraz przymierzyć się do odszyfrowania bloba DPAPI. Zaczynamy od rsaFlags.
- zaczynamy od wyliczenia HMAC z haszem wyliczanym zgodnie z algorytmem zapisanym w hashAlgo i długości hashLen, w naszym przypadku - HMAC-SHA512, przy czym jako entropię stosujemy zahardkodowany ciąg ASCII "Hj1diQ6kpUx7VC4m\0";
- wynikowe 64 bajty bierzemy jako klucz deszyfrujący w algorytmie symetrycznym (zgodnie z podanymi parametrami, w naszym przypadku: AES-256;
- dla pewności wyliczamy sign biorąc masterkey, hmac, entropię oraz blob (ciąg bajtów od początku bloba do końca cipherText, a więc bez ciągu sign i jego długości), korzystając z tego samego co w pierwszym punkcie algorytmu i porównujemy z zawartością pola sign. Jak się wszystko zgadza - znaczy, że nikt nic nie majstrował :)
Mając odszyfrowane pole rsaFlags bierzemy wynikowe dane jako entropię do odszyfrowania klucza prywatnego, przy czym masterKey pozostaje bez zmian (co zresztą wynika wprost z guida masterKey dla bloba powiązanego z kluczem prywatnym).
Stosujemy ten sam algorytm, co w przypadku rsaFlags i w wyniku otrzymujemy zestaw parametrów klucza prywatnego (Rys 13)


Szczegóły znajdziemy na Rys 14


Dla swojej wygody zapisałem parametry zgodnie z notacją, którą możemy znaleźć w implementacji algorytmu RSA Microsoftu w .NET Framework. Jeszcze tylko zrzut wszystkich elementów:

Dla tych, którzy nie znają ‘standardu’ rsa xml krótkie wyjaśnienie: bodaj tylko Microsoft korzysta w .NET Framework z takiego zapisu parametrów klucza prywatnego i powyższy ciąg może służyć do wypełnienia pól obiektu klasy RSACryptoServiceProvider, z użyciem metody o wiele mówiącej nazwie: FromXmlString(string xmlString). Ciekawostką jest fakt, że łańcuch base64 zawiera zakodowany odwrócony oryginalny ciąg bajtów danego parametru, nie jest to zresztą jedyne miejsce, gdzie odbywa się odwrócenie.

Kilka uwag implementacyjnych

.NET dostarcza przestrzeń System.Security.Cryptography, w której znajdziemy implementację zarówno funkcji haszujących, jak i algorytmów symetrycznych i asymetrycznych. DPAPI zapisuje używane przez siebie algorytmy w postaci liczby typu ALG_ID, jednak w .NET nie mamy wbudowanej metody fabryki, z której można skorzystać i wyciągać odpowiedni algorytm w oparciu o alg_id. Są za to abstrakcyjne klasy, które udostępniają metodę Create(string name), przy czym name trafia do klasy CryptoConfig, która ma zaszytych trochę algorytmów w postaci tablic haszujących. Najwygodniej wystrugać swoją własną klasę dostarczającą odpowiednie algorytmy + ich parametry, przyjmując alg_id jako parametr.
Kolejna uwaga dotyczy HMAC - na próżno w .NET Framework szukać HMAC opartego o SHA-512, ponieważ klasa HMAC ma zaszytą funkcją skrótu jako SHA1. Tu z pomocą przychodzi rozwiązanie opisane w książce "Security driven .NET", do lektury której gorąco zachęcam, więcej szczegółów na końcu serii.
W kilku miejscach pojawia się funkcja PBKDF2 i prawdopodobnie pierwsza myśl, jaka przychodzi do głowy, to skorzystać z klasy System.Security.Cryptography.Rfc2898DeriveBytes, która implementuje tę funkcję zgodnie ze standardem RFC2898. Niestety, oryginalna implementacja Microsoftu w DPAPI nieco odbiega od standardu i zamiast wyliczania hasza na podstawie oryginalnego hasza, tu wyliczany jest ‘hasz postępujący’, czyli po operacji XOR. Poniżej funkcja wyliczająca wraz z zakomentowanym w pętli ‘zgodnym ze standardem’ rachunkiem:

byte[] Func()

{

byte[] inputBuffer = Int2(this.block);

this.hmac.TransformBlock(this.salt, 0, this.salt.Length, this.salt, 0);

this.hmac.TransformFinalBlock(inputBuffer, 0, inputBuffer.Length);

byte[] hash =this.hmac.Hash;

this.hmac.Initialize();

byte[] buffer3 = hash;

for (int i = 2; i <= this.iterations; i++)

{

//hash = this.hmac.ComputeHash(hash);

hash =this.hmac.ComputeHash(buffer3);

for (int j = 0; j < BlockSize; j++)

{

buffer3[j] ^= hash[j];

}

}

this.block++;

return buffer3;

}

Oczywiście przy 1-2 iteracjach problemu nie ma, jednak przy 17400, jak to widzieliśmy w tekście, wyniki byłyby różne.

Ciąg dalszy nastąpi

Wygląda na to, że mamy z czym wracać do naszego zaszyfrowanego EFSem pliku. Mając wszystkie parametry klucza RSA możemy nareszcie zaatakować FEK i podjąć próbę odszyfrowania pliku. Pozostawiam to jednak na kolejny wpis, albowiem niespodzianek nie koniec i zapewne część z Was ulegnie temu samemu ‘ale jak to?! nie… coś chyba nie tak!’, któremu ja uległem swego czasu :)