Online Armor Firewall?

A HIPS' purpose is to detect attack patterns and block their source. Now with IP spoofing I'll simply spoof a number of legitimate hosts, send some of such attacks and the HIPS will block the legitimate hosts. Legitimate hosts are all internal server, the gateway, your DNS server, legitimate customers etc.

Buffer overflow in the kernel mode driver is fixed long ago, you can check it with bsodhook utility from Matousec. Though, the fact of a buffer overflow doens't prove vulnerability, it proves just insufficient parameters validation. In any case it is fixed which can be easily checked by anybody.

As for the shatter attack. The fact there are invisible windows doesn't mean vulnerability either. A program should be able to send the messages to those windows, which is impossible in OA case. So there is not any known vulnerability actually. I have found that exploit utility and tested OA. Exploit failed. Low level debugging showed "access denied" responce to the messages exploit tried to send to OA.

I'm OA beta teamer and I'm concerned about security, that is why I test everything by myself. ===

I fail to see how 'bsodhook' shall compete with the Driver Path Exerciser tool from the Windows Driver Kit. The problem problem is within buffer size vs. reported size, and a quick checkout clearly shows me that the most recent version of "Online Armor Firewall" is still vulnerable.

Of course it does, at least leading to a Denial of Service. However, this specific instance is clearly exploitable.

According to my analysis, it does work very well with WM_SETTEXT and WM_TIMER.

That's why serious people write their own exploits.

OK. This is well may be, but this is someth>

Have you ever reported this to the vendor ? And what was an answer ? Sebastian G.;3443166 Wrote:

WM_TIMER.

Can you publish your own exploit that anybody could use it ? I just doubt your words, sorry.

If a privileged system service opens windows at all, then this is a security breach.

Please have a look at:

Yours, VB.

comes to _SPECIAL_ service which _MUST_ protect other applications and services, do you think it cannot protect itself in the first place ?

Let me explain. The problem with WM_SETTEXT and WM_TIMER messages was discovered long ago and is well known as Shatter attack. Once specially formatted message was sent to the target service and was processed by _DEFAULT_ wndproc, YES, there is a way to inject your code in hte services's context.

But. If only service is developed with knowing of the nature of this attack it can handle those messages in special way. For one it can detect (using regular windows API) the source of a message and depending on this either process it or not. This can be done by ANY regular service. And when it comes to SPECIAL service, which controls system resources at the lowest possible level (RING 0 is meant here) there is not a problem to just laugh at this poor attempt to compromise security which OA succesfully does and which was proved by people who understand what do they do.

I can bet, nobody can sucessfully run Shatter attack against OA. I have read much of the attack and I have tried to run it myself against OA. There is just no way to send to OA service unauthorized message, because OA fully and globally controls windows message queue.

unauthorized message, because

queue. And that is to say this is equally valid not only for OA service, but for any OA related program, including OAui and scanningprocess and whatever it starts to provide security tasks.

And please, do not regard OA developers to be so silly not to handle such a well known issue in a safe way.

If the service were developed by people knowing about the nature of this kind of attacks it wouldn't have windows attached to it in the first place. There is no (in words "no") valid reason for a service to be running interacitvely with elevated privileges. If you need a configuration frontend for that service: write a frontend program that runs with user privileges and communicates with the service through appropriate channels (sockets, named pipes, whatever).

cu

This kind of issue should be "handled" by entirely avoiding it in the first place. Doing anything else will rightfully be considered plain and utterly stupid.

cu

wrote:

to be so silly not to handle

This kind of issue should be "handled" by entirely avoiding it in the

place. Doing anything else will rightfully be considered plain

stupid.

they do care about practical results. And practically nobody still succeeded to prove they are wrong. Until somebody succeed all the other talks are just fairy tails of nothing and commonplace speculations.

I can't resist to remember another fairy tail. Well known mr. Matousec forced many security vendors to believe that usermode hooks is "no-no" in security s/w. As a PoC he has published his FPR utility and claimed it unhooks all the usermode hooks of all the tested programs. Being sceptical about any claims I took this FPR, I took the set of Matousec tests and run it myself. Oops, FPR v3 failed to unhook OA usermode hooks (not all of them, but those only that serve as a helper security level in HIPS, CreateProcess and LoadLibrary) for ALL the tests. (To avoid misinterpreting I must add that OA has corresponding kernel hooks NtCreateProcessEx etc as the main protection level and uses usermode only to inform user faster and in more detailed way about what does happen, for example there is no way in NtCreateProcessEx to get commandline parameters just because this memory block is not setup by the system at this moment).

And now why was I sceptical about Matousec claim.

His main idea is "in its own memory application can do whatever it wishes and that is why usermode hooks can be unhooked in any case". Sounds quite reasonable, isn't it ? But this is not all the truth that must be taken in account. Another piece of truth is "to do anything in its own memory application must know what to do". To unhook usermode hooks application must know the addresses of the original functions. To get those addresses application must request some additional system resources (for example dll file that hosts original API function). But in case appilication is denied to get this resource (and security software that is deeply integrated into the system can surely restrict any system resource for the usermode apllication) it will not be able to unhook usermode hooks.

Coming back to avoiding something. I'd beware you from the too fast judgements. I saw many times people who judged fast was then very sorry about it. The fact you don't see the reasons doesn't mean there are not any. I can't say what considerations brought them there where they are, but I can judge the practical results (and I do it without extra words and fake considerations). My practical results with OA are excellent. There was some real (proved and reproducable) security issues found during betatesting, but all of them were fixed withing a couple of days after they were reported. Though, I don't remember that "commonplace considerations" were taken them too seriously. And this outdated shatter idea which first appeared when such a word as "HIPS" didn't even exist, can not be taken seriously today. This is not IMHO, this is my strong practical knowledge.

This only applies to non-broken concepts.

So then why does Online Armor Firewall use the DefaultWnfProc?

Which shows that you have obviously no clue.

This service doesn't run at ring0.

Look, I'll make this simple for you to understand: there's no point at all in solving a problem, when you can avoid it entirely.

That's what security is all about: defensive approaches. You try to avoid problems in the first place, and try to solve only those problems you cannot avoid. You may want to explain what would be invalid about this consideration.

It's utterly stupid to put yourself in danger first (for no good reason, mind you), and then defend yourself from the dangers you needlessly put yourself into.

That's entirely besides the point. I would never trust my security to anyone who disregards basic principles of security for no apparent reason, no matter how brilliant their code may be. Nor would I recommend any such product to anyone else.

cu

Matousec forced no one, except me to laugh.

Then again, just the existence of these hooks is proof enough how broken OA is.

There is no misinterpretation: OA is obviously broken.

And it's trivially true.

The original DLL is already loaded within KeLoadImage().

Nonsense. A simple ReadFile() already does the job. Anyway, one doesn't need it anyway, since you can link all required functions statically.

Well, of course it can. Just overwrite the relevant memory section. If not, then it's a bug.

Considering how enormously broken it is, this shows clearly how incompetent you are for judging security-relevant results.

However, some major bugs like f.e. blocking various legitimate device drivers, haven't been fixed.

Maybe I just misunderstood what you wrote, but isn't "HIPS" exactly one of the most unserious things?

I'm not a promoter, I just don't like when people blame something that works correct to be working incorrect. I have not a smallest intention to change your principle, even I regard them completely wrong. Here it was said that OA is vulnerable to the shatter attack. This is not true. And this is all I wanna say.

After all what I had to see, I would think so exactly, yes. There is no single reason for a privileged service to open windows, so only muppets are doing so.

I don't know, and I'm not interested in at all. I'm not talking about shatter attacks here.

Yours, VB.

If they're opening windows from a privileged system service, than "silly" is an euphemism.

They have no f*cking clue of Windows and security, if they're doing so.

Yours, VB.

You still have to give a single reason why that would be. You also failed to answer my question what IYHO were invalid about considering defensive approaches to security.

No. Volker said that shatter attacks are a *threat*. Which is absolutely true.

Opening windows from a service running with elevated privileges makes the service *potentially* vulnerable to shatter attacks. Whether there is or isn't a known vulnerability doesn't change anything about the threat being there.

cu