Delete Page Files for Security

Quote:

---

Originally posted here by str34m3r
Ok, I think you've both missed the point... The point is that not every system is a snigle boot machine. In fact, it's very easy to stick a floppy in a computer, boot it up from the floppy and read the hard drive. Now, one possible use of this would be to get the password file as you've suggested. But if you stop and think about it, that really has nothing to do with the page file anyway, now does it? The real value is that the system might have been working with the _unencrypted_ password file and swapped that out to disk. And if that file hasn't been wiped clean, you now have cleartext passwords lying around on the disk for anyone to read. Not good. Now on Windows NT, that not such a big deal since the NT password algortihm is so crappy and wouldn't take long to crack nowadays anyway. But on 2000 or XP, which have longer and better password agortihms, finding the passwords lying around in clear text negates that feature.

---

str34m3r,
Well, I hadn't missed the point, but I may not have made myself entirely clear...
What I was more interested in is the possibility of accessing such things remotely....

I mean, if you've got physical access to the PC, most security features of any PC (regardless of OS) can be overcome...

Quote:

---

aahh btw.. cracking the SAM file isnt really quite easy as the pwl file but the logic is almost thesame.. SAM takes up more time.. say.. i can crack SAM in 10 mins.. (depending on how fast the computer boots up or if the computer is able to boot by floppy.. coz if it cant.. i would need extra few seconds to crack the CMOS SETUP password).. pwl takes ermm.. roughly a min or so.. that is if u have access to MSDOS.. if not.. its gonna take another 10 mins..

---

s0nIc, that's not really correct... I've used utilities that crack NT/2000 SAM files, and there are a lot of variables... I mean, I've seen them unable to crack simple passwords, providing many # rather than the correct character....

And I'd like you to crack my password in 10 minutes... its only like 15 characters long....

LMAO 15 chars long?? fark.. give me 15 mins then! :P

Matty - I'm still looking up some of the info you were asking about. I have tried to remotely attack page files within my own network and have never had any success, even logged on as the Domain Admin. My assumption is that while in use the page file is locked (just as when you attempt to change the size of the page file you have to reboot in order to get the changes to take effect). But as I said that is an assumption.

There are many tasks in NT which must be run before NT starts and takes control of the system as evidenced by attempting to defrag the MBR on an NT machine with Diskeeper. Rather difficult to remotely attack an NT page file since the NT services have not started and the machine basically does not exist as far as the network is concerned.

And as for Win2K, in a pure Win2K environment, logons and authentication are handled through the KDS in Kerberos. Once the user has authenticated, they are issued a token (MD5) and the password transactions are destroyed. So they would not be in a page file to be accessed. (Of course all this depends on whether I have remembered it correctly - been a while since I stepped through Win2k logons.)

Then again, my headache could have me delirious, but that's what I recall... ;-)

in win2k you can also do this...and should....via local and domain security policy settings snap in...

this should also be enabled on laptops as this setting also clears the hiberfile.sys file (hibernation info)

also should make sure "Create a pagefile" rights is administrators only...

and HERE is a way to remotely exploit a pagefile...sort of

Quote:

---

My assumption is that while in use the page file is locked (just as when you attempt to change the size of the page file you have to reboot in order to get the changes to take effect).

---

you're right....when in use it's locked...

Quote:

---

2.2.5 Can my page file hold sensitive data?
It can. Memory pages are swapped or paged to disk when an application needs physical memory. Even though the page file (see Control Panel->System->Performance->Virtual Memory) is not accessible while the system is running, it can be accessed by, for example, booting another OS.
There is a registry key that can be created so that the memory manager clears the page file when the system goes down:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\MemoryManagement\ClearPageFileAtShutdown: 1
Note that the clearing of the page file only is done when the system is brought down in a controlled fashion. If the machine is just switched off or brought down in any other brute way, of course no clearing will be performed.

---

http://www.it.kth.se/~rom/ntsec.html#host-pagefile

In my education in NT, I have learned that page files are always inaccessible while the OS is running. But - there is a priviledge that can be granted (Act as Operating System) that is not granted to any user or group as default. This is saved for services and such, but can be assigned to users and/or groups. Unfortunately, this still does not allow access to all subsystems, therefore I am not even sure this will allow access to the page file.

Now that I have my "NT hat" on, in order to access the page file directly while the OS is running, the request must come from the file subsystem itself to access information in the page file. So - in short I don't think its possible to access it remotely.