Re: DNS changed...
From: Bill Sanderson (Bill_Sanderson_at_msn.com.plugh.org)
Date: 10/02/03
- Next message: Bill Sanderson: "Re: New Trojan that affects DNS, McAfee deems this as "QHosts-1""
- Previous message: Mike Beauchamp: "DNS changed..."
- In reply to: Mike Beauchamp: "DNS changed..."
- Next in thread: Mike Beauchamp: "Re: DNS changed..."
- Reply: Mike Beauchamp: "Re: DNS changed..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 2 Oct 2003 00:46:51 -0400
Mike - here's a rather technical description from NTBUGTRAQ which might (or
might not!) help you:
This explains perhaps half-a-dozen posts I've seen over the last 4 days or
so mostly complaining that Google has stopped working with a reference to
something bad having happened to the hosts file.
Note that the vulnerability involved is MS03-032. It'd be interesting to
know if you are patched on this one?
See the link at the very end to read other messages in the thread this
belongs to:
(From Russ:)
----------------------------------------------------------------------------
----
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
-----
Wondering as to whether the list is running? The NTBugtraq archives are
updated first before messages are emailed to subscribers. Check the
archives first to see if you have missed any messages;
http://www.ntbugtraq.com/archives
----------------------------------------------------------------------------
---
-----
"Mike Beauchamp" <newsgroups@mikebeauchamp.com> wrote in message
news:blg89l09b3@enews2.newsguy.com...
> Hey all..
> I just had one of two home computers on a network stop being able to do
> anything on the internet. So I checked the connection settings and noticed
> that the DNS had been changed to:
>
> 216.127.92.38
>
> When I searched groups.google for that IP I found this site:
>
> http://vil.nai.com/vil/content/v_100719.htm
>
> I tried following the removal instructions but there were some
> inconsistencies. I found the hosts file where the page said it would be,
as
> well as a new WINDOWS directory created on my F drive with a few other
> directories in it but no files. I checked my registry and couldn't find
>
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
> Services\Tcpip\Parameters\Interfaces\windows "r0x"
>
> I also couldn't find
>
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
> Tcpip\Parameters "DataBasePath"
>
> so I couldnt' change it back to what it should. However, every interface
has
> "hostname" set to "216.127.92.38" but I don't know what I should change it
> back to.
>
>
> Of course, I went to Windows Update.. and found 0 critical updates. Then,
on
> my other computer (which DIDN'T have this virus), I found 16 critical
> updates (fell behind I guess..) but the installation has crashed...
>
> It's all weird considering I've never got a virus in years and the only
> thing I've downloaded recently is ironically Ad-Aware 6.
>
> Mike
> http://mikebeauchamp.com
>
>
- Next message: Bill Sanderson: "Re: New Trojan that affects DNS, McAfee deems this as "QHosts-1""
- Previous message: Mike Beauchamp: "DNS changed..."
- In reply to: Mike Beauchamp: "DNS changed..."
- Next in thread: Mike Beauchamp: "Re: DNS changed..."
- Reply: Mike Beauchamp: "Re: DNS changed..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
