Russian Coreflood gang targets banks

http://www.usatoday.com/money/industries/technology/2008-07-15-coreflood_N.htm

 

For an analysis of the exploit see:

http://www.secureworks.com/research/threats/coreflood/?threat=coreflood

---

 

Interesting.

 

A corporate network user browses an infected site, which utilizes a drive-by exploit in an common ActiveX control in IE. If this ActiveX control was not patched, then when the network admin logs in on to that workstation sometime in the future, every desktop in the entire network could become compromised throught one workstation's vulnerability. Geez...

Unless I'm mistaken, running under a limited user account (even without SRP) should prevent this particular exploit since ActiveX controls cannot install in any way that I know of without admin rights. But if the user runs as admin with just an AV (the AV might catch it), then you better be using thorough patch management software. That, or hope an admin never needs to log in to the network on the infected workstation to fix a problem.

 

This is why Firefox and Opera should be used more.

 

Are you referring to a drive-by download/installation, or a manual installation of the ActiveX control?


----

 

Sorry, I misstated the reason.

This exploit would be prevented under a limited user account because the vulnerability in the already installed ActiveX control limits the exploit code to functioning with the privileges of the user running IE, according to CERT. I'm assuming that's correct.

Running with limited rights, registry entries for the exploit could not be written, nor would executables be allowed in the windows\system32 directory, where the exploit places code.

It could infect just the user account, if it's code that's LUA aware (assuming no SRP). But someone would have to log in to the computer as the limited user and then also log in to the network as an administrator (not just use the same workstation), in order for the trojan to penetrate the rest of the network, I would think.

As far as installing ActiveX controls, my understanding is they cannot be installed without being admin.

 

why do big banks use windows?
linux and unix based OS are much better for reliability,stability and secuirity.

 

at least here in holland there is a tendency to shift to Ubuntu,some big companies are already in transition,but i guess its a temporary solution the story will repeat itself if the major companies are on linux so they will again target of the maliciosa.

 

For those running as Admin, the control can't be installed by remote code execution if you have protection to block unauthorized executables. ActiveX controls are .ocx and .dll.

With such protection , the exploit couldn't run in any case since it attempts to download/install a trojan executable. See Post #2.


---

 

to the rescue let it be Sandboxie,it gives you complete control,just an example others are more used to Defence Wall or Returnil or Shadow Defender and dont forget Anti Executable,if used these maliciuos stuff is quite harmless.

 

Sandboxing, software to block unauthorized executables, LUA+SRP, disabling ActiveX and not using IE, etc., are all very effective solutions, no doubt.

 

A question in my mind has been, at what point does the attack stop in a system running in a LUA?

ActiveX exploits have been in the news lately, so consider this one using the Snapshot Viewer ActiveX Control exploit
that is analyzed in different places on the internet. Here is part of the code.


__________________________________________________


Testing the Exploit - non LUA

Microsoft Snapshot Viewer ActiveX Control Arbitrary File Upload Vulnerability
http://tools.cisco.com/security/center/viewAlert.x?alertId=16222

Code:

obj.CompressedPath = buf2;
var buf2=mycars[x]
mycars[0] = "c:/Program Files/wsv.exe";

Now, I run as Administrator on my Win2k system, yet I know that nothing can install without my permission:


___________________________________________________

You will notice that Anti-Executable's Alert is Default-Deny. The only other solution I've seen that is Default-Deny
is Software Restriction Policies. For those who haven't seen an SRP alert, here is one from a previous
test, courtesy of SpikeyB:


____________________________________________________________________________

Why emphasize Default-Deny? When something attempts to sneak in, there should be only one course of action:
Deny Permission to Execute.

Do you think the exploit will run in a LUA? Nothing installs into windows\system32. If so, when would it stop?

Now, you can argue that if wsv.exe did download in a LUA account, it would be stopped from making any changes to the system files or installing into the Registry, but you are left with one or more files installed somewhere in the User directories to clean up, depending on what the exploit did before it was stopped.

An interesting exploit which attempts to install an ActiveX control by remote code execution is described here
(I found it posted on another forum)

ActiveX Vulnerabilities: Even When You Aren't Vulnerable, You May Be Vulnerable
http://www.securityfocus.com/blogs/977

I could not find any URLs to try, so I set up a test to attempt download a control that is not already on my system.
Again, with proper protection, the ActiveX control (an executable) cannot install no matter what.



________________________________________________________

As far as the snapview control exploit, if you want to test your LUA and IE configurations, you can search online for that topic
and you will find a number of websites that talk about it and you can get the URL.

The point of all of this is that in theory certain things are supposed to require Administrative privileges to run; IE is supposed to require this or that, but in practice configurations change and there are too many variables and possibilities for mishap in remote code execution exploits.

A strong Default-Deny protection at the door negates these concerns.


----