Short version:
---
Ppl are activly exploiting the, still unpatched, Internet Explorer HTA vuln. This vuln is ~1-2 weeks old now, still no real patch from microsoft. Be afraid, be very afraid =).
---
Long version:
---
Yesterday NTBugtraq was informed of an active attack against users of
Internet Explorer. I'd like to thank Steve Shockley for informing me.
The attack comprised of a banner, hosted by FortuneCity.com, which in
turn used Java-Script to redirect the self-closing "pop-under" banner to
a site hosted by EV1.NET (Everyone's Internet.) An EV1.NET site then
delivered executable code which in turn invoked the HTA vulnerability.
The HTA vulnerability is a known and as yet unpatched vulnerability in
IE.
Interestingly, vulnerability was described thoroughly by Thor Larholm on
Monday at the 5th annual NTBugtraq Retreat, prior to notification of the
active attack. He explains it much better than I, but my short version
is;
When the Object Data vulnerability is exercised, IE renders and executes
the ActiveX object referenced in the hahahahahahahahahaha code. During the check
to determine whether the content is safe, IE mistakenly believes the
ActiveX object code to be simple HTML/Jscript. Therefore, it does not
prompt to save to disk. Subsequently, it remembers it is HTA content,
and invokes MSHTA.EXE to drop and execute the object code. That code is
x[1].hta, which in turn creates and executes AOLFIX.exe.
AOLFIX.EXE is downloaded into the \temp directory and executed, and
deleted.
It caused a variety of actions;
1. It created empty directories called;
%systemdrive%:\bdtemp
%systemdrive%:\bdtemp\temp
2. It deleted AOLFIX.EXE
3. It created the following file, which contains the letter "A";
%systemdrive%:\%systemroot%\winlog
4. It created a hosts file in the \%systemroot%\help directory which
contains numerous static IP address to search engine website mappings.
5. It created the following registry entries;
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\Parameters\I
nterfaces\windows]
"r0x"="your s0x"
"NameServer"="69.57.146.14"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\Parameters\I
nterfaces\{45F95E82-B443-428B-9EB7-4C65CDCD9006}]
"NameServer"="69.57.146.14"
HKEY LOCAL MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Pa rameters
"DataBasePath"="%SystemRoot%\help"
At last check (8:15pm EDT 10/1/2003) the banner page at FortuneCity.com
was still serving up the banner which leads to the malcode.
We have received reports from many locations around the world indicating
they have had the effects of this. NAI is calling this QHOSTS-1, see
http://vil.nai.com/vil/content/v_100719.htm for more details.
Thus far there isn't much you can do beyond disabling Active Scripting
(Georgi's old mantra.)
If you apply "default deny", the concept that your perimeter only allows
out that which you have permitted, then outbound DNS by clients will
fail, making them unable to browse or do anything involving DNS
(including internal DNS resolution.) If you don't use "default deny",
consider doing so, or block outbound DNS (port 53) to thwart the
replaced DNS entries.
Personal Firewalls which understand and can block specific applications
from accessing the network (such as Zone Labs, Symantec Personal
Firewall, see what you get if you come to the Retreat!), should be
configured not to allow MSHTA.EXE. The use of MSHTA in this attack
doesn't prevent everything, but it should prevent the redirected DNS
from occurring.
Thor Larholm explained to me why disabling the HTA MIME type works. I
really should've been paying closer attention to his talk rather than
trying to talk over him...;-] Anyway, although IE is failing to properly
handle the content type application/hta when it checks if it should do a
save-as dialog, it does use it when it comes to render. Hence, it
doesn't pop up, but it does use the MIME type to determine what to
invoke when it renders. If you lose the key, even if only temporarily,
it won't find MSHTA.EXE.
It is worth noting that disabling ActiveX (any of the number IE entries
which relate to ActiveX) will do nothing to prevent exploitation of this
vulnerability. The problem lies in the way IE perceives the content, and
while it should recognize it as ActiveX, it does not. Hence disabling
ActiveX will not provide a mitigator.
More tomorrow.
Cheers,
Russ - NTBugtraq Editor
---