tommy wrote:
> xml exploit [ aka Exploit:JS/Agent.IHL ]. Announced on Dec 12, 2008 by
> Microsoft in their bulletin. Affects Internet Explorer 7, and all other
> versions of Internet Explorer. Security hole mentioned in thread "Serious
> security flaw found in IE"
>
> It's a bad one, no known anti-virus program can remove it at this writing
> [ AFAIK ]. Wiping the disk and reinstalling are the only known cures at this
> time.
>
> It is known to inhabit the servers at certain places in youtube and myspace,
> anong others.
>
> You can still get it even if you use only good websites, because it can
> inject itself across the databases shared by sites.
>
> A friend in the business reports having 7 systems infected in his backlog,
> and a shop nearby has overflow of 12 or so. [ Houston, Tx Northside] thurs
> , 12/18/08
>
> anybody see it yet in your area? [ haven't seen it mentioned by name in this
> group since 12 /17]
Well, you could:
- Use GeSWall, a policy enforcer and which runs the web browser within
an isolated environment more restrictive than using just an LUA token.
Alas, there are times when GeSWall can get in your way and apparently it
won't let you run Java applets (not Javascript but Java).
- Use DropMyRights or SysInternals psexec to run the web browser under a
LUA (Limited User Account) token to restrict its privileges, like not
being able to install software. However, these only use the LUA token
on the instances of the web browser that they load, not on other
instances of the web browser that are started as child processes by
other programs, like your e-mail client (when you click on a URL in an
e-mail). Of course, having to do this only applies to those users that
insist on logging under an admin-level Windows account rather than using
a limited/standard account. If you use Vista with IE7, and if you left
UAC enabled (so IE7 runs in its protected mode), the limitations of LUA
and more are already applied. These may not prevent the exploit from
occurring but limits the privileges of the malicious code that it
attempts to run as the payload. LUA mode or IE7 protected mode will
mitigate the effectiveness of the malware payload of the exploit.
- MS08-078 lists 8 methods of blocking the attack until you decide to
finally get around to applying the update.
- Go to Windows Update site and obtain the MS08-078 security update that
was available there as of yesterday (Dec 18). See:
http://www.microsoft.com/technet/sec...n/MS08-078.msp
http://support.microsoft.com/kb/960714
So do you really have access to the *servers* in which the exploit code
was deposited (that would then affect your visit to that site)? The
*exploit* in the web browser means that it might run *code* on your host
that would've otherwise been limited by the Javascript engine
incorporate to the web browser. "The vulnerability could allow remote
code execution if a user views a specially crafted Web page using
Internet Explorer." The payload of the malicious code that might get
executed on your host is not the exploit itself, so your antivirus
program will have to detect whatever is that payload to neuter it.
Again, this is a client-side exploit in the web browser, not something
to fix on the server other than to remedy the corrupted web pages.
Servers are not where end users are using web browsers. This is a web
browser (client) exploit, not a problem with the web server software
running on the server host. There's nothing to fix in the web server
other than repair/restore the code in their web pages (it is not an app
issue on the server but a content issue). It's a client-side problem.
Of course, some admins do use their server hosts as clients and browse
from there (which is dumb).
For the servers, probably the easiest way to cleanup would be to restore
their web pages or databases from their backups rather than dig through
them to find where the exploit code got inserted. They'll have to
discover what was the infection vector into their server host to plug
the hole and prevent reinfection, like SQL injection attacks that
attempt to propagate the malicious code across sites via shared
databases (this is a different attack and not specifically related to
this client-side only exploit).
http://msevents.microsoft.com/CUI/We...CountryCode=US
http://blogs.technet.com/msrc/archiv...-released.aspx
http://www.microsoft.com/technet/sec...ry/961051.mspx
Your antivirus software will have to detect the payload that got
delivered due to the exploit. The exploit itself must be remedied
within the web browser. It's not the exploit that your antivirus has to
detect or repair. It's the exploit's payload and that can vary at every
infected web site. The primary sites that incorporate (perhaps
deliberately) this exploitive code are pornographic sites. Well, I
guess you get what you deserve. Unsafe hex also has its STDs. So
although the bad code is on the site, don't expect them all to actually
do any cleanup. Some of them really want to utilize that exploit by
their visitors that have chosen not to update their web browser. In
fact, after every monthly update that includes fixes to IE there are
lots of malicious sites and HTML-formatted e-mails that try to take
advantage of those bugs knowing that many users procrastinate on doing
Windows updates.
Removing the exploit means you go to the Windows Update site and getting
the update. Handling the [viral] payload of the exploit is up to your
anti-virus, anti-malware, and HIPS programs to handle.
Similar Threads
