ProcessGuard Security Flaw

Discussion in 'ProcessGuard' started by UpQuark, Nov 27, 2005.

Thread Status:
Not open for further replies.
  1. UpQuark

    UpQuark Guest

    This is my first post here, so I beg the wise people here to be gentle with a rookie like me...
    English is not my mother language, so excuse any grammatical and syntax errors.

    First of all I want to say that in my opinion ProcessGuard is simply the best security program I know. And I've tested and used many security programs in the last 5/6 years (HIPS, Firewalls, Anti-Virus, Registry Protectors, etc).

    Well, that said, I'm here to report a ProcessGuard's serious security flaw.

    ProcessGuard saves all it's configuration (and GUI password) in the following file: "C:Windows\system32\pguard.dat".

    ProcessGuard saves all hashes of the always allowed or always denied executable files in the following file: "C:\Windows\system32\pghash.dat".

    Both this files (pguard.dat and pghash.dat) are protected by the driver (procguard.sys) ProcessGuard installs or by the service (DCSUserProt.exe) ProcessGuard installs. I think and hope (for the sake of security) that it is by the driver. I will make a test to see if it is the driver or the service that is protecting those "dat" files, but in the mean time perhaps someone from DimanondCS could clarify this subject.

    Those ".dat" files are so well protected that, without disabling protection on ProcessGuard's GUI, it is not possible to copy, move, delete or simply access those files.

    But there is a simple way to bypass that protection and so turning null all the protection offered by ProcessGuard.

    1- Hacker X has physical access to the victim hard drive.
    2 - He access the victim’s hard drive booting from another computer/hard drive or from a bootable CD-ROM (Sysinternals Administrator's Pak, for instance).
    3 - He then substitutes "pghash.dat" existent on victim's PC by a fake version of "pghash.dat" containing the hash of a trojan version of program A (depending on circumstances, and in order to make that substitution, Hacker X would need to have physical access to victim’s PC just one time or two times).
    4 - He substitutes Program A by a Trojan version, with the same name, of that program (let's name it "Program B", for it there will be now a correct hash on file "pghash.dat).
    5 - When victim executes Program B he will think is executing Program A and ProcessGuard will remain absolutely silent (because the new "pghash.dat" contains now Program's B signature hash and not Program's A signature hash.

    The same could be done, in exactly the same way, with the file "pguard.dat", thus modifying ProcessGuard's configuration without victim consent or knowledge.

    What could DiamondCS do in order to eliminate this security flaw, thus turning ProicessGuard's into an almost impenetrable security program?

    ProcessGuard should always work, in real-time, with two versions of the referred “dat” files (pghash.dat and pguard.dat): a protected version and non-protected version. Off course the non-protected versions of pghash.dat and pguard-dat would always be exact copies of the protected versions.

    Then, all the user needed was to maintain, on another local, copies of the non-protected versions of pghash.dat and pguard.dat and compare those copies with the originals at every Windows boot and shutdown.

    Those copies could even be stored within an PGP encrypted disk...

    And the comparing process could even be done on the very beginning of the boot process... One could, for instance, make a simple batch file with comparing instructions that could be started as a service, using a program like "FireDaemon"...

    Perhaps the wise man form DiamondCS could comment on this security flaw and on the suggested ways to eliminate it.

    StrangeQuark
     
  2. TNT

    TNT Registered Member

    Joined:
    Sep 4, 2005
    Posts:
    948
    Ok, sorry, I read this and I couldn't even be bothered with reading the rest. If one has physical access to the victim's hard drive, he can do all sort of things and there is NOTHING to prevent him from modifying system files apart from a "whole drive" encryption, and even with that, the owner of the computer has to disassemble the machine and check that the computer is physically intact every time, because many hardware keyloggers exist.

    Jeez, I have no idea while this is brought up over and over again. People should really start learning that physical access has NOTHING to do with an application vulnerability.
     
  3. devicenull

    devicenull Registered Member

    Joined:
    Nov 4, 2005
    Posts:
    3
    If he's got physical access like that, he could just as easily dump the windows passwords, crack them, reboot into the OS, install a trojan and give it full access in PG... How many users would really study the list of allowed stuff every time they boot up?

    The way to eliminate it? Set the bios to not boot from CD/USB, password it. As long as your computer isn't easy to take apart, that will stop most of the people who would do that.. Would you notice someone taking the case off of your computer?

    Or if you are that worried, lock up your computer..
     
  4. TNT

    TNT Registered Member

    Joined:
    Sep 4, 2005
    Posts:
    948
    Well, he said "physical access to the hard drive", so it seem that he really means the attacker also has the option to the out the HD and attach it to another computer. I have another idea, though, I think Process Guard is vulnerable to denial of service: if an attacker has physical access he can take the hard drive and smash it with an axe, and Process Guard DOESN'T PREVENT HIM FROM DOING SO! :D
     
  5. Mestrinho

    Mestrinho Registered Member

    Joined:
    Nov 27, 2005
    Posts:
    1
    It is obvious that ProcessGuard is a very good program, no one should be without. Even (mostly) for those whose PCs are subject to being used by more than one person. I myseld try to protect my PC and its contents from eventual prying eyes and all kind of stuff such as trojans, virus, etc... using several tricks (even home-made) ... but without ProcessGuard, this would be a difficult task!

    I myself am a programmer and I am in the pc/software business for many years now. Having the necessary tools, it is relatively simple (lol)... to configure a PC in such a way that we know if someone has tampered with it. But to be able to do so, ProcessGuard is a MUST HAVE. So... it's obvious that ProcessGuard should be "flawless"... but in fact, it is difficult but possible to "fool" it into thinking all's well.

    If an authorized user was to access the "protected" PC without booting from the installed operating system, and replced the files pguard.dat and pghash.dat with adultered but correct versions of these same files but reflecting changes to one or more of the suposedly protected programs, all would be well to ProcessGuard when in fact I could for example have replaced some programs with older (or newer) versions...

    Would it not be possible for ProcessGuard to have a "non-protected" (eventually encrypted) copy of these two files so that a user could make a simple comparison with backed-up versions of them ? Wouldn't this render ProcessGuard even more secure ?
     
  6. UpQuark

    UpQuark Registered Member

    Joined:
    Nov 27, 2005
    Posts:
    4
    Well, I think some people here are completely missing the point...

    The ideia is not prevent someone that has physical access to the hard drive to destroy the information existent within that hard-drive or to make a copy of all information... Off course there is no way to prevent from that, besides perhaps staying all day in front of the computer with a shotgun. That idea would be so silly I never dreamed someone could interpret the post in that way...

    The ideia is to prevent someone that has physical access to the hard drive to steal or read the encrypted information existent on that drive... If a hard disk is not full encripted (a process with many inconvenients...) then someone with just a little bit of privacy concern saves all private information on encripted form... say within a PGP Volume or something like that...

    So the idea is to avoid someone that has physical access to the hard drive to place in it a trojan or software keylogger that could steal and save or send the passwords used to encrypt and deencrypt the private data...

    When the victim turned on the compromised PC ProcessGuard could easily prevent the autostarted trojan from running... The victim would be immediatly alerted that a new or modified program was trying to execute...

    But because of the referred ProcessGuard's security flaw an hacker could bypass ProcessGuard's protection.

    If ProcessGuard worked with the referred non-protected copies od pguard.dat and pghash.dat (the same way many anti-virus and firewall programs already work these days) the victim would make the comparison mentioned on my first post on the very begining of the boot process or just after logging in, and then immediatly knew someone had tried to compromise de computer and then the victim would not write de passwords needed to access the encripted data...

    Beside I think many people here are "forgeting" that the hacker's ideia is many times to try obtain information that it will be created by the victim in the future or private information that the victim already has on the hard drive but on encripted form...

    UpQuark

    PS: I thought no one here ignored how easy it is to clear CMOS ans its password, so the BIOS suggestion is not valid.
     
  7. TNT

    TNT Registered Member

    Joined:
    Sep 4, 2005
    Posts:
    948
    Right, except if an attacker has physical access to the hard drive, he can substitute the Process Guard executable so that it's always allowed to execute his own trojan (without even showing it in the "allowed executables" list!), and he can replace the "hashing/comparing/whatever" instructions so that they always report the old value (even though the files really have changed) thus make the whole process utterly useless.

    You want to encrypt the files with PGP? Well, the attacker creates a trojaned PGP on your hard drive which shows you a (fake) "incorrect password" the first time you write it, then logs it the second time thereby decrypting the files and storing or communicating the correct password for the attacker to get it. You think you would notice? How many times does it happen that you type an incorrect password? Or he can install a rootkit that gives you fake information on the .dat files (size, time of modification etc), making you believe you're still looking at the files you had, but really they are modified.

    Really, there hardly a way to prevent this if you have physical access. This is not related to Process Guard at all.
     
    Last edited: Nov 27, 2005
  8. TNT

    TNT Registered Member

    Joined:
    Sep 4, 2005
    Posts:
    948
    How?
    You can't... the mere fact that he has access to the (unencrypted) hard drive means he can install ANYTHING.

    No, he wouldn't. An attacker could have replaced Process Guard with his own trojaned version.

    The referred flaw is not a flaw in Process Guard, it's a flaw in your understanding of a basic security concept: physical access == "rooted" machine.

    Again, not true. The attacker could have trojaned Process Guard to ignore this. He didn't have anything to bypass: all he needed to do is modifying the Process Guard executable. The attacker could have replaced executables that give you information about files with trojaned versions, so that the information about the files mentioned above would be the same, although the files really are different.

    So?
     
    Last edited: Nov 27, 2005
  9. UpQuark

    UpQuark Registered Member

    Joined:
    Nov 27, 2005
    Posts:
    4
    Well, some people here ignore basic security concepts and procedures.

    No, an hacker could not modify or install fake versions of PGP, ProcessGuard executables, important system files, etc (without the the victim knowing) simply because the first thing a wise user makes when he boots an operating system is to compare all those files with copies of them existent for instance on a USB disk, encrypted volume, etc...

    But with a program like ProcessGuard, that controls execution, the user almost only needed to compare all ProcessGuard's files and all files of the encryption programs.. If those files where correct, the user would know, for instance, that no new services where started, no new drivers, no new programs were started without his permission, and so on...

    Offcourse the compare program (or file integrity checker) also would execute from the encrypted volume or from a USB disk, etc....

    The reason because this king of security isn't bulproof is because ProcessGuard has a serious security flaw that prevents the user to control the intigrity of the files where ProcessGuard saves all its configuration and hashes!!!

    This serious security flaw is even more strange because many firewalls (ZoneAlarm and Outpost, for instance), anti-virus, etc, use these days the referred defense: two versions of the some file: one protected and one not-protected.

    But DiamondCS could use other basic security measures that would greatly improve ProcessGuard's security and contribute to eliminate the serious security flaw I'm talking about: for instance encripting all the contents of pguard.dat and pghash.dat !

    In fact I'm curious to know why ProcessGuard does not encrypt all the contens of those files, thus for instance avoiding that the attacker could know what hash belongs to what executable.

    ProcessGuard, in my opinion, should create not-protected copies of the files where it saves the configuration and the hashes, thus allowing the user to control if those files and therefore the all system was, or was not, compromised!

    I'm still waiting for a valid, honest and no fundamentalistic argument on why this measure woul not greatly improve the security given by ProcessGuard.

    Besides I think ProcessGuard is perhaps the only security produtc in the world that does not allow an user to control (by comparing, producing signature hashes, etc) the files where is saved its configuaration !

    It's a serious security flaw, and a security flaw not present in almost any security product in the world!
     
  10. Paranoid2000

    Paranoid2000 Registered Member

    Joined:
    May 2, 2004
    Posts:
    2,839
    Location:
    North West, United Kingdom
    If an attacker is able to replace or alter the pguard.dat and pghash.dat files, then they can compromise your system in a number of other (easier) ways so to call this a PG "vulnerability" is rather pointless (like saying Windows has a vulnerability because you can boot up off a floppy with NTFS drivers and access every file and folder).

    Ultimately if you are concerned about protecting against someone who has physical access to your PC, the proper security measure is whole disk encryption. Then even if your disk is stolen, the data is not accessible without the correct password.
     
  11. TNT

    TNT Registered Member

    Joined:
    Sep 4, 2005
    Posts:
    948
    Meaning you? Yep. I've been working as a professional programmer and web application security analyst for 8 years, what are your skills?

    Oh really? You check the Process Guard, PGP, system files executables, system drivers, etc every time you boot the OS? And from where do you check them anyway, from another operating system where NO ONE has physical access so you can be sure that one was never compromised? Are you a comedian?

    NOT ONE of those security programs will give you protection against physical access. NOT ONE.

    But anyway, there is no point in discussing this further. Seriously, your concept of host security is rubbish.
     
  12. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    17,050
    This is really silly. If he has access to the machine, then he doesn't need something even low tech. If he knows about Process Guard, he just disables it. Geesh.

    If you don't want something looked at by someone who has access to your machine, put it in an encrypted file, with a strong password.

    Moreover if others besides whom you trust have access to your machine, then I'd put nothing private on it.

    Duh.
     
  13. TNT

    TNT Registered Member

    Joined:
    Sep 4, 2005
    Posts:
    948
    It still woudn't prevent a skilled attacker with physical access from reading its contents, since he can replace the decryption executable with a trojaned version that logs the password. He would just need to wait until he can access the machine the next day or something. :D

    Of course we are always talking about a skilled attacker here, which is always what you should assume the attackers are. :D

    Definitely. The point here is, it is EXTREMELY hard to prevent some skilled attacker with physical access to do whatever he wants. Whole disk encryption is the first part of the solution, and without that, a system is automatically exposed in every way.
     
  14. UpQuark

    UpQuark Registered Member

    Joined:
    Nov 27, 2005
    Posts:
    4
    Paranoid2000: Thanks for your response.
    All disk encryption is the best security measure agains physical access, of course, but it has some disadvantages, such as system performance degradation, incompatibilites with different programs (disk defragmenters, etc).
    Besides no security expert would use a non-opensource whole disk encryption, and at the present moment PGP Whole Disk is the only open-source (although payware) application that offers whole disk encryption.

    Besides usually the only files requiring encryption are the personal ones (medical or clinical data, financial data, private letters, private pics, private emails, etc). So why encrypt whole disk if we don't need to encript applications, Windows, non-private data, etc? That's why Linux users (with a few exceptions, only encrypt Home Directory.

    The best pratical attack against the more simple and widely used file ecryption and volume encryption (even PGP only introduced whole disk encryption about six months ago) is by installation of a keylogger in the hard disk of the victim.

    As you surely know the method FBI and similiar institutions use to access the private information encripted by PGP or similar encription applications is to install a keylogger on hard disk (in absence of the victim).

    That's why almost anyone around here concerned about keyloggers use Registry protection or monitoring applications, such as RegDefend, RegRun, and so on. Certainly they also have heard about whole disk encryption...

    Well, the method to gain access to encrypted data has been installing a keylogger on victim's hard disk...

    ...But:
    1 - The keylogger, in order to operate, must start at least next time the victim turns on the PC.
    2 - The keylogger must install or operate as a driver, a service or as a normal program.
    3- PGP will block or notify user if a new service, driver or program wants to start...
    4 - User don't deencript files or volumes before (as a minimum security measure) comparing ProcessGuard files with copies saved for instance on a USB Pen or disk he has on pocket (this operation performs in a few seconds).
    4 - Offcourse user will not write password or open encripted files ou volumes if a suspect driver, service ou executable tried to start... And then he will investigate and eliminate the "trojan".

    But, and there is one more "but"... it happens that user could not compare the critical files I'm talking about (pguard.dat and pghash.dat) due to a critical (in my opinion) ProcessGuard's security flaw: the fact that ProcessGuard don't allow the user to compare those files with copies located elsewhere!

    Even if you have a different opinion you certainly agree that if ProcessGuard allowed the user to check the integrity of pguard.dat and pghash.dat the security of system woul be greatly improved... Don't you think?

    If not why are almost all of us using file integrity checkers and programs like "NIS File Integrity Checker", "Prevx", "System Safety Monitor", "AntiHook", etc?

    If whole applications were just like ProcessGuard is was virtually impossible to check integrity on disk, all we could do were controling the integrity on memory...

    Please don't get me wrong. For me ProcessGuard is just the best security application I know of. For me those guys from DiamondCS are genious.
    Bur the program has this problem that in my opinion is a serious security flaw, and a security flaw that it certainly could easily be eliminated.

    Paranoid2000, I thank you for your responses because your opinions are of great value for me.

    PS
    There could be other aways for an attacker that has physical access to a victim's PC to record encryption passwords, but the method described is the only one that we know of and that is currently beeing used by authorites and hackers.
    Besides the attacker has a great disadvantage: he doesn't know the victim is doing file comparasing or file intigrity checks and wich files are beeing compared...

    ~Useless dribble removed....Bubba~
    UpQuark
     
    Last edited by a moderator: Nov 27, 2005
  15. TNT

    TNT Registered Member

    Joined:
    Sep 4, 2005
    Posts:
    948
    False. It can be triggered by an executable, or be attached to it by modifying one ("trojan-ing" one).
    False. PG (I think you meant Process Guard, not PGP, which is a completely different program) itself could have been modified not to do this, because an attacker with physical access could have replaced it with his own version.
    If the files used for comparing the executables have been modified (and they clearly could have been, since the attacker has access to them) they can show you false reports. You wouldn't notice a thing. This is not sci-fi, the most sophisticated UNIX rootkits replace a lot of files like ls (to list existing files and their properties), md5/openssl (to verify checksums), netstat (to look at connections), etc. They have been around for AGES. You need a different computer altogether, one you can trust. One where an attacker couldn't have physical access.
    More absurdity. You could have the impression that the files are the same when they aren't, 'cause the OS you're using can't be trusted anymore. Hell, you could have the impression of "deleting" the trojan while the trojan really is still active and well.

    You can do this. Boot from a floppy, copy them on it, store them in a secure place, do it every time after you turn off the PC. Will this prevent you from being hacked? NO.

    No.
     
    Last edited: Nov 27, 2005
  16. Bubba

    Bubba Updates Team

    Joined:
    Apr 15, 2002
    Posts:
    11,271
    I have taken action on a couple of posts. Let's Please keep the personal dribble to ourselves and contribute based on the thread topic.
     
  17. TNT

    TNT Registered Member

    Joined:
    Sep 4, 2005
    Posts:
    948
    Ok, sorry for that. I know, I often have a terrible way of expressing my thoughts. :(
     
  18. UpQuark

    UpQuark Registered Member

    Joined:
    Nov 27, 2005
    Posts:
    4
    TNT: I'm begining to think you don't even read what I write.
    But in spite of that I want to thank you for being more polite in your later response. I think we are all here to learn with each other.

    TNT wrote: False. It can be triggered by an executable, or be attached to it by modifying one ("trojan-ing" one).

    Wrong, any modification like that would be noticied by ProcessGuard. ProcessGuard's saves hashs of all applications you have allowed. If the application were trojaned ProcessGuard would block i or show an alert pop up.

    TNT wrote: False. PG (I think you meant Process Guard, not PGP, which is a completely different program) itself could have been modified not to do this, because an attacker with physical access could have replaced it with his own version.

    Wrong. If ProcessGuard have been modified I would know it because ProcessGuard is the primary deffense against hackers and so its files (except pguard.dat and pghash.dat...) were being compared against copies of them saved on a USB disk or, for instance, on an encripted volume without private information, just de copies...).

    TNT wrote: If the files used for comparing the executables have been modified (and they clearly could have been, since the attacker has access to them) they can show you false reports. You wouldn't notice a thing. You need a different computer altogether, one where an attacker couldn't have physical access.

    Wrong. There are many simple ways to avoid this modification of the program or files used for comparing.
    I made a little program that makes the comparasion and it runs from a USB pen that is always on my pocket...
    But I have other ways to avoid the modification of the program and files used to make the integrity checks... If you want to know I also use NIS File Integrity Checker which I run from an encripted volume.
    Of course if the PC had just beeing compromised the password used to open that encypted volume has ust beeing saved on an file... But that would happen only seconds before the comparasing had finished and so seconds before I knew the PC was compromised... The attacker would not have the time to get that file. And even if he was hiding on the same room as I were no problem. Remember that the private data resides on other encrypted volumes protected with different passwords. And if the comparasing detects a modification of course I do not open the encrypted data.

    TNT Wrote: More absurdity. You could have the impression that the files are the same when they aren't, 'cause the OS you're using can't be trusted anymore. Hell, you could have the impression of "deleting" the trojan while the trojan really is still active and well.

    Wrong. Read my response to your last argument. I've already explained how the integrity check can be done in an almost totaly secure manner. Of course theoretical an attacker could have modified even the operating system kernel and in a manner that ProcessGuard coul not detect. He could, for instance, have modified the OS in such a way that all comparasions were correct even if the original was different from the copy. But that would not be easy and it would be a sort of a pionner kind of attack. And I have some protection against those theoretical attacks. I don't want to reveal much here, but one of the things I do is to have a copy that is intentionally different from the original.
    But I'm not saying that if ProcessGuard allowed the user to check the integrity of pguard.dat and pghash.dat one could build a buletproof security system. All I'm saying is that if ProcessGuard had not the referred security flaw the security offered by it would be greatly improved.

    IT'S VERY IMPORTANT TO BE ABLE TO CHECK THE INTEGRITY OF THE FILES WHERE A VITAL (first line of deffense) PROGRAM LIKE PROCESSGUARD SAVES ITS CONFIGURATION AND SIGNATURE HASHES. Excuse the caps, I had not the time to learn how to put this on bolde.

    TNT wrote: You can do this. Boot from a floppy, copy them on it, store them in a secure place, do it every time after you turn off the PC. Will this prevent you from being hacked? NO.

    Of course I could do that. But I'm not a sadomasochist. I'm paranoid about security but not so paranoid. :) The file inegrity checks and deencryption of files referred above are only a matter of seconds... Besides it would be easier for DiamondCS to eliminate the security flaw. It would be a pain for the user if he had to use such a method.
    That would not prevent me from being hacked, but if my own program is good and if ProcessGuard is as good as I think, then being able to check the integrity of pguard.dat and pghash.dat would greatly improve the security of my system and it would be at least much more dificult for the attacker to hack me.

    And remember that the attacker has no way to know that I'm making the integrity checks... He doens't know all the elements of the kind of defense I use... He would almost certainly use the method of placing a keylloger, not other ultra expensive, difficult and stratospherical ways of compromising the system, such as trying to modify the kernel in ways not detectable. And for that method of placing a keylogger if I could do the integrity check of those files it would be almost impossible for him to hack me without me knowing.

    Even FBI and CIA use the method of placing keyloggers. As a matter of fact they have created some keyloggers and this is the method they are using, not patching kernel or similar ways.

    Against a keylogger, even a keylogger placed by someone with physical access to the hard drive, ProcessGuard can be a very efective deffense. Next time user logged in the OS the keylogger would be blocked or detected, especially by someone using other programs like RegDefend. But not if user can not check integrity of all files belonging to processguard.

    I have so much confidence in ProcessGuard that I think it can give great protection even against physical accesses to a computer... This means I think ProcessGuard is an extraordinary program, don't you think? It's a pity it has that serious security flaw...

    UpQuark
     
  19. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    17,050
    Hi Upquark.

    I think you are beating a dead horse. I would suspect what you are calling a security flaw, would probably just bring a chuckle to software developers. PG is designed to defend against the high probablity attacks. What you are describing if I read you right is such a low probability scenario as to not warrant consideration.

    If the FBI, and CIA, really had an interest in your activity, and had physical access to your computer(and it's environs) ain't nothing anyone could do to PG that would help you.

    Pete
     
  20. Wayne - DiamondCS

    Wayne - DiamondCS Security Expert

    Joined:
    Jul 19, 2002
    Posts:
    1,533
    Location:
    Perth, Oz
    Hi UpQuark, welcome to the forum. ;)

    Can I ask why you are posting here instead of contacting us directly? If you believe you've found a security issue with any software by any developer then do the right thing and email the vendor privately. Then you can discuss it with them and work out if it really is a problem, and if so then the developer will have time to develop a fix before the problem is made public. This is called responsible disclosure, a practice followed by security experts and professionals but encouraged to be used by all. Everyone has made some good points, and if you'd like to continue this discussion feel free to private message me or email me.

    Regards,
    Wayne
     
    Last edited: Nov 27, 2005
Thread Status:
Not open for further replies.