This is a bit off topic, but for anyone who doesn't monitor the NTBugTraq
list, check out the following post. I've already had one user get nailed.
Steve
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 JavaScript 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 JavaScript 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\Services\Tcpip\Parameters\I
nterfaces\windows]
"r0x"="your s0x"
"NameServer"="69.57.146.14"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\I
nterfaces\{45F95E82-B443-428B-9EB7-4C65CDCD9006}]
"NameServer"="69.57.146.14"
HKEY LOCAL MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
"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
---
This e-mail has been scanned for viruses by the anti-virus systems of CyberShift, Inc.
The information contained in or attached to this message is intended
solely for the personal and confidential use of the designated
recipients named in the body of the e-mail or within the attached documents.
This message may be legally privileged, and as such is confidential. If the
reader of this message is not the intended recipient or any agent responsible
for delivering it to the intended recipient, you are hereby notified that you
have received this document in error, and that any review, dissemination,
distribution or copying of this message is strictly prohibited.
Thank You, The CyberShift NOC
---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.Virus mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.Virus". The archives can be found
at http://www.mail-archive.com.
