The June 16 Security UPDATE includes a link to the news story "New IE Flaws Might Allow Code Injection," which describes a relatively new attack method being used by both intruders and purveyors of suspicious or malicious software to infest systems that use Microsoft Internet Explorer (IE). Jelmer Kuperus said that the attack uses Javascript, iframes, PHP, and timing techniques to gain access to the trusted intranet zone on a user's system. According to Kuperus, the exploit also "uses several known vulnerabilities and two previously unknown vulnerabilities." One of the vulnerabilities, for which no patch exists, involves ActiveX Data Objects (ADO).
http://www.winnetmag.com/article/articleid/42959/42959.html
Through this attack method that uses multiple vulnerabilities, many people's systems (possibly even the systems of some of you readers) have become infected with various sorts of software, most of which is annoying, if not outright dangerous. For example, nefarious entities have installed adware that generates an endless stream of pop-up windows on users' systems. That's the lighter side of the problem though.
As you can learn by reading the news story "Vulnerable IIS Sites and IE Users Under Attack" below, yet another factor was added to the mix last week, this time involving Microsoft IIS. Using the IIS vulnerability described in Microsoft Security Bulletin MS04-011 (Security Update for Microsoft Windows) on systems that haven't yet been updated with a patch that's been available since mid-April, intruders can inject Javascript into a server's Web pages. The Javascript then uses a technique similar to the one I described above to get IE to download Trojan horse software onto an unsuspecting user's systems. The Trojan horse program then gathers ("phishes") log-on and financial information.
So now instead of intruders having to establish their own Web sites to host malicious Javascript code, they're penetrating unpatched IIS systems around the Internet that host legitimate Web sites. As Bugtraq mailing list moderator David Amhad points out in a June 25 posting, these combined vulnerabilities have "no dependence on version or memory layout or any other such messy factors, firewalls are totally irrelevant and VPNs become basically a free ride in, [and] the browser doesn't end up crashing (i.e., the victim remains blissfully unaware that they've been owned)." These combined vulnerabilities have the potential to become devastating.
http://www.securityfocus.com/archive/1/367120/2004-06-25/2004-07-01/0
Some preventive steps are obvious, and some aren't so obvious, depending on the user or administrator. Obviously, loading the IIS patch MS04-011 on your servers will stop intruders from manipulating the servers' Web pages into hosting malicious code. Turning off scripting in the IE security zones will also protect users to a certain extent. But in countless scenarios, turning scripting off just isn't possible. And sometimes scripting is essential to a Web site's usability. Many of you probably already know how to improve security in IE, but in case you don't, Microsoft has some recommendations that you can read at the following URL:
http://www.microsoft.com/security/incident/settings.mspx
One workaround if you can't turn off scripting is to disable ADO databases (ADODB) in IE. Drew Copley of eEye Digital Security wrote a simple registry script that does this very thing and one that undoes the changes. He also wrote an executable program that disables and re-enables ADODB. You can download the scripts and executable program at the eEye Web site.
http://www.eeye.com/html/research/alerts/al20040610.html
Another way of protecting IE systems against ADODB attacks is to use PivX Solutions' Qwik-Fix, which protects IE against a variety of intrusion methods. Recently, the company made available a version of Qwik-Fix for enterprise environments. I don't know of any other tool that provides the same sort of functionality.
http://www.pivx.com
Register
