defeat human identification?

Hi,

pgMsgProt.exe is configured by default to allow Read access by any process. Does this mean that a troyan could possibly read the Human Identifaction code from the memory space of pgMsgProt while the HID dialog is displayed? Or is the code stored elsewhere during the HID dialog?

regards,
hojtsy

 

Hi hotjsy, No a Trojan could not read the code generated for the HID - As far as I know the "Read" only means that other programmes can see what the file or process is, not what it is actually doing.

The default allow flags are actually allowing pg_msgprot.exe to "read" etc other programmes on the Process Guard list not "to allow" access, as all the other listed programmes are protected by PG's driver this is necessary to allow programmes to function correctly.

For instance if you have Task manager (TM) listed and do not allow it to terminate TM cannot terminate a listed programme. If, however, you want TM to be able terminate a listed programme then you would allow TM the terminate flag.
Personally I do not allow TM to terminate listed programmes and only enable the allow flag when necessary.


HTH Pilli

 

Hi,

I am not talking about the allowed privileges, but about the blocked privileges. The blocked privileges for pgMsgProt.exe does not contain the Read, meaning any process can read the full memory area of pgMsgProt.exe. In this matter the settings in the allowed privileges is not important because we are not interested in what pgMsgProt.exe can do, but what other processes can do to pgMsgProt.exe.

regards,
hojtsy

 

Sorry hotjsy, I obviously did not see that you were refering to blocks and not allows

Other programmes may need to read pg_msgprot.exe but they cannot use that information to alter it or any other listed programme.

 

But the code I need to enter to the Human Identification dialog is present in the memory area of the pg_msgprot.exe, isn't it? Then

1) a trojan could send a disable message to PG
2) the Human Identification dialog is displayed
3) The trojan reads the code to enter from the memory area of pg_msgprot.exe
4) The trojan enters the code
5) PG is now disabled.

 

As far as I know it would have to hook the process and this is forbidden providing you have enabled Block global hooks in General protection as then processguard will not allow SetWidowsHookEx. I suppose it may be possible if you listed an untrusted programme such as a Trojan and gave it the allow global hook flag and or suspend / terminate allows.

I am not a programmer but I hope DCS will post a more thorough and accurate answer

 

Please specify which of these actions need a registered global hook, and which not:
2) Sending fake mouse clicks/keypresses/gui events to the procguard.exe window.
3) Sending fake mouse clicks/keypresses/gui events to the Human Identification window.

br,
hojtsy

 

Not sure, you will have to await Jason's comments but wouldn't that require a .dll injection? In which case PG would stop it.

 

I don't see where is the pb because :

first : you need to know at which memory address the code is stored in the memory and you have no way to guess it

second : if DCS has well done PG, the code is stored in an encrypted form which can't be reversed (let's say MD5 or SHA-1) and then, when the user type the code, PG should encrypt it and compare both encrypted signature.
In this way, to have access to the encrypted form does not lead to any clues of what is the letters expected.

I let DCS to answer may be more technically, but i think you shoudln't worry.

 

Security through obfuscation? You should do better than that! A trojan writer could reverse engineer PG and find the address just like hundreds of "software loaders" which crack software protection exactly by finding code and data portions in the memory space of active processes.

I disbelieve DCS cared to store it an encrypted form for two reasons:
1) the code should be generated in cleartext, and reguralily coverted into the noisy picture of the dialog. With one-way encription it would be impossible to generate the noisy picture again and again, because you would not have the code to print into it. Also the code could be stealed during the (random?) generation of it.

2) The problem is easily circumvented by blocking read access to pgMsgProt.exe, and only allow privileged processes to read it. But this could only work in the full version because there may be as much as 4 or 5 software which needs read access to it. (AT/AV etc)

So it seems to me that users of full version have an unsafe default setting, but users of free version are unable to set it safely at all. Before saying that messing with the memory space of an other process is too complex to do for a troyan, consider why you have PG after all.

regards,
hojtsy

 

absolulty not, it's easy to misread args, my point wasn't the first point only, but the first AND the second point, which together are _not_ obfuscation.

i disagree, it can indeed be done like that, but all i see is the same picture, with his "x" and "y" moving, and colours changing, so in clear, the same picture with parameters randomly chose each 2s, so at this point the code can be generated an only time.

see my previous arg.

Not necessarely, you can generate directly an encrypted form, with functions within functions like :

MD5(create_text(random seed, 5))

Of course technically the plain text form is in memory one millisecond (even less i think) and i think it's very hard to catch it.

you have the answer, that was what i done since my first full version.

Interesting... what is your definition of "safe" ?
If you mean by safe to be protected from ANY possible exploit, usable or
extremely theoritical, then ALL the softwares default settings (firewalls first) are unsafe.
A default setting, whatever the software, isn't the higest setting and the highest security, which can lock up a computer and prevent the user to do what he wants.
Default settings are often a bare minimum, which should be tighen up regarding individual computer and each configuration (different from users to users).

So i would more say that with default settings, users are not protected from a theoritical exploit (until you show me a program doing it) highly unlikely to happens, and that they can _easily_ protect them from it with the solution you have said yourself.

again the problematic definition of "safe", users _are_ safe from ITW threats and exploits.
Then, a free version is to trial a software, you don't buy it, so don't expect to have all features from the full version. I know a ton of trial softwares having one or two features missing, it isn't a big news.

I am not at all saying that, again it is easy to misread args purposefully or not.
I am doing it actually (playing with memory of other processes) and because it is possible and used ITW by trojans i use PG.
But actually to inject a thread or a DLL is easier than to wait for a memory piece of information only available 1ms.
If *I*use PG before all, it isn't for theoritical exploits trying to read information in memory, but before all to protect what i want from being terminated or modified.
THEN, i indeed block all READ/GET INFO on all my protected processes, but that's not a big issue for me, at least just need to block them for pgmsgprot.exe

 

No difference. Then the clear picture is stored withouth encription (or with reversible encryption) for a longer time period in a freely readable memory area. Then the noise in the displayed one provides no increased safety.

And then how do you generate the initial picture? Call unMD5?

In my perception the exploits that PG is made against, is in the same magnitude that this possible exploit would be. I agree that default settings for most security software are Bad. But PG is for the power user, as compared to most AV and firewall. At least there could be an explanation of this issue during PG installation, and then I could select for the safe-but-complex blocking of Read access to pgMsgProt.exe.


All this encrpytion thing is theory. We are just guessing what DCS could implement, but they have not told what they have implemented. It is even possible that the code is stored in a more secure place, for example in the kernel driver. I would be more content to hear some facts from DCS rather then this guessing around.

regards,
hojtsy

 

Agreed, I have informed DCS about ths thread & I expect they will reply tomorrow morning.

 

If you are a dev like me, we both know what is possible from what it isn't, and everything else is just personal opinion, i have give you mine, explain why, and now think what you want, it's a public forum to _share_ ideas and to ask questions, not to bit each other
Personally i would rather ask IF they were any protection and would have waited for answer instead of telling people PG is insecure (ok i little over exagerate but it's for the picture), but i guess it's a matter of personality.

You have said me that some things was "the same" and i disagree, because both things are "possible" doesn't mean that they are identical.

Indeed, no one else than DCS has a better place to know how his software works, let them answer to you, i think not until next Monday.

regards,

gkweb.

 

I'ts a public holiday in Western Australia today so we probably won't get more info' until tomorrow (Tuesday)

 

hojtsy and gkweb - Please verify that this is the way to go with this:

All protected processes need to be given "Read" access to PG_MSGProt.exe after blocking read access to PG_MSGProt.exe

Thank you. Pete

 

Hi, first off PG does not store the 5 digit number in an encrypted form yet, but it easily could if there was some point in doing so. A program could just keep polling memory whilst the program is generating the sequence though AND who knows if Windows doesn't keep that string somewhere else when it is drawing the text anyhow (likely it does keep it).

The reason we didn't worry about any of the above is because you can set the block READ flag which makes it all redundant. With block read this problem and many others are solved. The reason it isn't a default option at this stage is because it would generate many log alerts to the inexperienced user. It's just like saying why aren't all the general protection options enabled by default? For the same reason.

Finally you need to block read access on each program you have enabled Close Message Handling on, if you want to stop some malware from possibly reading the sequence. PG_Msgprot.exe does not contain the sequences of numbers, rather each process which has CMH enabled does. So for instance if I had Close Message Handling on Outlook and I wanted to stop a program from possibly reading the sequence during a WM_CLOSE, I would add BLOCK READ to Outlook so nothing but protected programs WITH allow READ can read it's memory.

-Jason-

 

Thank you Jason,
It is clear to me now.
Could you please include this information in the help text of PG for Close Msg Handling?

regards,
hojtsy