Failure of HIPS?

Rmus,

It'd be helpful to check your processes list to see if the spoofed GIF is indeed running as a process when the downloads occur. I have difficulty believing that any HIPS worth its salt would fail to block a CreateProcess API call if the rules are configured properly, and would be very interested to see if this is indeed the case.

 

I don't have a HIPS, but see aigle's 2 posts starting here:

https://www.wilderssecurity.com/showthread.php?p=1010173#post1010173

where he shows that his HIPS blocked the executable from being launched by something else.

Is this what you are referring to?

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

Am I correct to conclude that if the redirect occurs the executables could download to the browser cache folder and perhaps the startup folder but will not actually launch? SSM, PS and other HIPS of course would not detect these unless they attempt to launch, and it looks as though AE detects them because that is how it works: it detects new exe's placed in the system, even before they launch?

I'm just trying to piece together everything I've read in this and several other related threads and links in an effort to summarize it all into something that makes sense. It's a bit confusing sifting through all the information posted from those who have tried this Still, it is very interesting and a good learning experience

 

@Kenjin
I think ur analysis is true. In that case i will be satisfied.

@ Rmus

Hi Rmus, As I said before AE warned u about download of executable( .gif) not its actual execution( that why it is saying Reason: Copy). Gif file was never excuted on my system or on your system. Is is possible to repeat the test while setting AE to allow copy of un-authorized executables but deny their actual execution( if there are any such settings for AE)?

Thanks

Also I wonder is there anyway to log all the events in real time and then to analyze them later on. I just checked and GeSWall,s log also shows no entery of .gif file but ther are enteries for MS_update .exe.

 

Hi Rmus, It was GeSWall and it,s log has no entery for gif file but there is entery for MS_update.exe.

 

I think exactly in the same way now.

 

Well, here is my take on it. Feel free to suggest other things:

1) There are two URLs involved in the redirect.

The first is to 85.255.115.221 which caches a page that connects out to 69.50.184.59 which is the source of the WinAntiVirus page. This can be seen in my screen shots of the page sources.

2) Several HTML pages cache and one of them has code to download cnte-oiduuyes.gif which is a spoofed image file. These HTML pages use obfuscated javascript, so without converting to readable text, it is not possible to accurately know the minute details of this exploit.

3) AE blocks the download of cnte-oiduuyes.gif because it detects it as binary executable code. That is all AE does, nothing more. That is its sole function in life.

4) At this point, nothing can continue because until cnte-oiduuyes.gif caches, the already-cached HTML page which will copy cnte-oiduuyes.gif as MS_update_0704_KB74073.exe sits waiting... and waiting...

5) As far as I am concerned, the game is over. The exploit is dead in the water: it can't do anything.

But, out of curiosity, I let cnte-oiduuyes.gif cache and ended up with those executable files I listed. IExplore then crashes, and a hidden process of IExplore starts. At this point, I disconnected from the Internet and killed the IExplore process.

From here, I don't know what the exploit does. I would like to be able to decipher the code of those HTML pages. Next week I'm going to speak to someone about this.

And that is all I know!

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

Rmus,

Allow me to clarify myself. What I hoped you could verify, was that the spoofed GIF was indeed running as a process and was the culprit responsible for the silent downloads, which might very well have been due to other classical IE exploits that had nothing to do with the spoofed GIF whatsoever.

AFAIK GesWall and AE act differently from classical HIPS, in the sense that you don't need to tighten their rules as much (which reduces the margin of error causes by an incorrectly-configured ruleset). What I'm interested in, is if this behavior is really consistent for everyone else - that SSM, ProSecurity etc will fail to block execution of the spoofed GIF assuming their rules are configured properly.

 

solcroft,

I was not able to verify that, but yours is a good point because earlier in one of these threads I noted that one of the cached files was riff_last[1].bin which contains .ani code (you might recognize 'riff') and another file is cnte-ani_dthcbdg[1].html which has the same code as the other 2 cnte-xxxxxx.html files, all of which I think are three different IE exploits to trigger the download of cnte-oiduuyes[1].gif.

The fact that the cnte-oiduuyes[1].gif does not attempt to download using Opera leads me to think that these are all IE-specific. But that is conjecture, without seeing the code.

My speculation is that the other executable files are triggered by MS_update_0704_KB74073.exe but without seeing the other source codes, it remains speculation.

BTW - AE has no rules: it is Default-Deny.

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

Rmus,

I finally got the chance to run the file in a test environment today. From what I've been able to observe, the file first terminates all running instances of iexplore.exe, launches a new invisible instance of it as a child, then tries to install a global hook from a spoofed DLL file (renamed with a .tmp extension). From that point onwards, the child iexplore.exe process is hijacked to download and drop multiple files in the %windir%\system32 folder, neither of which are named ms_update*.exe.

From what I've seen so far, the drive-by downloads seem to have no connection with the spoofed GIF; indeed, I doubt it was ever executed at all. For one, the most obvious symptom of that happening would be to have all your IE windows suddenly killed, which I've yet to see anyone mention in this thread...

 

Solcroft, Rmus, Aigle,

Thanks for this thread. This pretty much ends the discussion in another thread (regarding ProcessGuard being still up to date). The statement was "I can not infected when I do not allow executables to start".

Some members argued that with drive by downloads you sometimes are not aware of starting programs due to executable code hidden in normally non-executable files. Others mentioned unpatched OS-vulnabilities.

This is why a properly configured XP Pro or an XP Home with a policy sandbox forms a good combo with any Anti-Executable or Behavioral blocker (at least that is my opinion).

This thread was very informative to read thanks again guys.

Regards K

 

Hello, solcroft,

I got a different result. Maybe this exploit does different things on different computers

I set my firewall to alert and walked through the exploit.

Until cnte-oiduuyes[1].gif downloads, nothing happens, as I indicated in previous post.

When I permit cnte-oiduuyes[1].gif to download,

http://www.urs2.net/rsj/computing/imgs/cnte-gif.gif
____________________________________________________________________________

the first 2 files I see created are

MS_update_0704_KB74073.exe in the C:\Documents and Settings\.......\Startup directory. and

tmp11.tmp in the C:\Documents and Settings.....\Temp directory:

http://www.urs2.net/rsj/computing/imgs/files_1.gif
____________________________________________________________________________

I think cnte-oiduuyes[1].gif is copied as MS_update_0704_KB74073.exe.
Kenjin and I came to the same conclusion in Posts #24, 25; the scans show they are
the same file. cnte-oiduuyes[1].gif just sits in the cache -- it's job is finished.

Now, IExplore immediately crashes and a new process of IExplore starts (hidden window)
and attempts to connect out to inhoster.com:

http://www.urs2.net/rsj/computing/imgs/kerio.gif
____________________________________________________________________________

After letting it connect, I check again for files created and three files are installed in C:\WINNT\System32\

http://www.urs2.net/rsj/computing/imgs/files_3.gif
____________________________________________________________________________

I killed the IExplore process, re-enabled AE, let things sit for a while, and as I was typing, I was alerted that
MS_update_0704_KB74073.exe attempted to create another .tmp file.
BTW: AE alerts are Default-Deny. There is no option to permit.

http://www.urs2.net/rsj/computing/imgs/ae_alert.gif
____________________________________________________________________________

It seems like MS_update_0704_KB74073.exe is the workhorse. Being in the StartUp Directory, it of course
will run on every bootup and connect to inhoster.com hidden from view. I executed the file manually and immediately
a new process of IExplore started along with two MS_Update_0704 processes:

http://www.urs2.net/rsj/computing/imgs/kerio2.gif
____________________________________________________________________________

http://www.urs2.net/rsj/computing/imgs/processes.gif
____________________________________________________________________________

I looked up ipv6mons.dll and it is used with several trojans as a BHO.
(you can probably purchase it on the black market!)
So, I restarted IExplore. Definitely hijacked:

http://www.urs2.net/rsj/computing/imgs/ipv6mons.gif
____________________________________________________________________________

So, if this exploit is successful, there will be a continuous connection to inhoster.com hidden from view,
and in your normal work with IExplore, you will have a nice Helper to assist you!

That's all I know...


regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

Most of this thread is far beyond my understanding, but, I find it very interesting and very important.

I do very much appreciate the summary/recap as to what you experts think is happening in post #32.

I also appreciated @Kees post #36 to help put this in "housewife" terms. (Thanks Erik.)

In post #4, I said, "That is why I have IE with a security policy set as a BASIC USER."

What I mean by that statement is, I have a Local Security Policy > Software Restriction Policy set on my IE 6 so it runs as Basic User instead of the factory default of Unrestricted.

So, to finally get to my questions...
1) This works only for IE 6?
2) Since I have IE restricted to Basic User (can not write to %SystemRoot%), I am not vulnerable to this exploit?
3) In affect, that Policy is similar to what @Rmus said, "BTW - AE has no rules: it is Default-Deny."?
4) In affect, that Policy is similar to what @Kees said, "or Behavioral blocker"?
5) So, at least in the exploit, me not having any HIPS (yet), I was not, can not be infected?

"housewife", Mike

 

Well, if that's the case, then it's indeed a nice explanation for everything. Your observations are consistent with what I've seen so far, and so there's the answer to aigle's question: HIPS programs don't prompt the execution of the spoofed GIF, because it's been copied under a different name with a proper .exe extension. Nothing to sweat about.

 

OK, I am confused again, but maybe I am comparing apples to oranges.

Per this post https://www.wilderssecurity.com/showpost.php?p=1010399&postcount=248 it seems they do? can? execute.

Confused, Mike

 

If all you do is double-click, then Windows will check the associated extensions list and use the appropriate program to launch the appropriate file. In other words, if you rename an .exe file to gif, txt or something else and double-click on it, Windows will try to use the associated programs to open that file - Notepad, Paint, etc.

There are, however, ways to force a CreateProcess API call from a file with a non-standard extension. In short, you can't execute a renamed executable by double-clicking on it, but that doesn't mean you can't execute a renamed executable via other methods.

Hope that makes it clear.

 

Yup, very clear!

Mike

 

My knowledge is very limited on this but I think Rmus sums it up very nicely in post #37.

 

Hi Hees, my assumption of gif file excution not detected by HIPS seems wrong, so above statements still stands correct.

 

If there is no connection, why this gif file is downloaded as the very first diveby? U should rather say" there is no execution of gif file"

I agree.

It happened each time and I very clearly mentioned it in my post. However the culprit was not gif file rather other executables.

 

Hi Rmus, can AE be configured to allow download/ copy of executables but to deny their execution.
If it is possible to set it like this, then u can try with these settings. Now if gif file is ever executed, AE will prompt and block it. If gif file is not executed, the first file to be executed will be MS_update.exe, that will be blocked with prompt by AE.

 

Regarding my statement:

A friend uses this description. Paraphrasing her:

• The initial file is an executable "payload" often with a spoofed file extension, and the renamed file with extension .exe becomes the downloader. In practice, the "payload" does not execute itself. Code in one of the cached files copies it to another location with a different name, whereupon it will connect out to the internet and download more junk. The original "payload" file just stays in the cache. That they are both the same executable file is shown by scans of the files.

You can think up your own description.

Looking back at some other exploits, here are two which use this technique.

Trojans: Payload and Downloader

I haven't let one of these exploits run like I did this SloanTreeFarm site in awhile - you really need good logging tools to follow everything closely. Coding is becoming trickier to follow. And besides, they all do the same thing anyway,
so it becomes borrrrring....

I'm not intending to make light of this, but this type of remote code execution, aka drive-by download, is blown way out of proportion, IMHO. This is due to the way these exploits are written about in the media. They usually have a comment like, "You only have to view the web page to get infected with loads of spyware, adware..."
Well, that is just a bunch of malarkey! - because on closer scrutiny, it becomes evident that they are very easy to block.

So, using this SloanTreeFarm site as an example to test, what are some solutions?

1) You block at the outer perimeter, so to speak, where the payload executable
is prevented from downloading - cnte-oiduuyes[1].gif in this case.

==> Browser

screamer wrote,

Many exploits are Browser-specific. This one seems to work only on IE6. I could not get the download to work in Opera.

==> specific execution prevention software is "supposed" to prevent this:

• Abtrusion Protector was one of the first
• Process Guard (its execution prevention feature]
• FreezeX - which later evolved into Anti-Executable
• ExeLockdown
• _________ others??

I've tested only Anti-Executable and I plan to test PG and Abtrusion Protector later.


2) You block at the inner perimeter so to speak, where the "payload" caches but the exploit is prevented from doing anything. In this case: MS_update_0704_KB74073.exe is blocked.

==> aigle showed how Geswall and an AV both jumped in when that file executed.

==> SpikeyB uses Software Restriction Policies (SRP) and he says nothing gets through his gate.

==> flinchlock asks,

How does "Basic User" limit the actions permitted? You would have to test carefully.

==> ___________ others?? Test if you can.


So, there are a number of solutions. Take your pick, and tell others who worry about this type of exploits that a solution is at hand!

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

No.


regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

That,s not pleasant.

I wonder why they did not added more features/ configration options.
That might had lead to it,s more popularity. It seems very rigid, no so suitable for home systems.

 

I tried it with DropMyRights and the malware exes were able to download and execute.