New Exploit

[Invision]

i been getting multiple ws on my network where the DNS are being change by a malicious code

I didn't find anything at Symantec or Microsoft, but I found this on ARIN WHOIS search:

http://ws.arin.net/cgi-bin/whois.pl

Search results for: 69.57.146.14
OrgName: Everyones Internet, Inc.
OrgID: EVRY
Address: 2600 Southwest Frwy., Suite 500
City: Houston
StateProv: TX
PostalCode: 77098
Country: US

NetRange: 69.57.128.0 - 69.57.159.255
CIDR: 69.57.128.0/19
NetName: EVRY-BLK-13
NetHandle: NET-69-57-128-0-1
Parent: NET-69-0-0-0-0
NetType: Direct Allocation
NameServer: NS1.EV1.NET
NameServer: NS2.EV1.NET
Comment:
RegDate: 2003-06-20
Updated: 2003-07-02

TechHandle: RW172-ARIN
TechName: Williams, Randy
TechPhone: +1-713-400-5400
TechEmail: admin@ev1.net

OrgTechHandle: RW172-ARIN
OrgTechName: Williams, Randy
OrgTechPhone: +1-713-400-5400
OrgTechEmail: admin@ev1.net

# ARIN WHOIS database, last updated 2003-09-30 19:15
# Enter ? for additional hints on searching ARIN's WHOIS database.

Search results for: 69.57.147.175
OrgName: Everyones Internet, Inc.
OrgID: EVRY
Address: 2600 Southwest Frwy., Suite 500
City: Houston
StateProv: TX
PostalCode: 77098
Country: US

NetRange: 69.57.128.0 - 69.57.159.255
CIDR: 69.57.128.0/19
NetName: EVRY-BLK-13
NetHandle: NET-69-57-128-0-1
Parent: NET-69-0-0-0-0
NetType: Direct Allocation
NameServer: NS1.EV1.NET
NameServer: NS2.EV1.NET
Comment:
RegDate: 2003-06-20
Updated: 2003-07-02

TechHandle: RW172-ARIN
TechName: Williams, Randy
TechPhone: +1-713-400-5400
TechEmail: admin@ev1.net

OrgTechHandle: RW172-ARIN
OrgTechName: Williams, Randy
OrgTechPhone: +1-713-400-5400
OrgTechEmail: admin@ev1.net

# ARIN WHOIS database, last updated 2003-09-30 19:15
# Enter ? for additional hints on searching ARIN's WHOIS database.
And here is the tracert data:

C:\>tracert 69.57.146.14

Tracing route to 69.57.146.14 over a maximum of 30 hops

1 <10 ms <10 ms <10 ms 10.22.2.3
2 <10 ms 15 ms <10 ms 10.22.14.5
3 16 ms <10 ms <10 ms 10.90.248.14
4 <10 ms <10 ms <10 ms 10.90.250.90
5 <10 ms <10 ms <10 ms 10.90.250.126
6 <10 ms <10 ms <10 ms 10.90.250.157
7 16 ms 15 ms 16 ms 10.90.253.201
8 16 ms 15 ms 31 ms 10.241.7.37
9 31 ms 31 ms 32 ms 10.241.7.97
10 32 ms 31 ms 31 ms col-01-dir.msdwis.com [172.28.129.11]
11 16 ms 15 ms 16 ms fw-col-01.msdwis.com [204.115.161.61]
12 32 ms 31 ms 31 ms 4.17.247.193
13 31 ms 32 ms 15 ms fa0-0.deanwitter8.bbnplanet.net [4.17.247.98]
14 47 ms 47 ms 31 ms s5-0-4.chcgil1-cr1.bbnplanet.net [4.24.149.13]
15 15 ms 32 ms 31 ms p5-0.chcgil1-br1.bbnplanet.net [4.24.5.241]
16 31 ms 31 ms 31 ms so-3-0-0.chcgil2-br1.bbnplanet.net [4.24.9.69]
17 32 ms 31 ms 31 ms unknown.Level3.net [64.159.4.1]
18 47 ms 47 ms 47 ms gige8-0.hsipaccess1.Chicago1.Level3.net [64.159.1.222]
19 31 ms 47 ms 47 ms unknown.Level3.net [166.90.80.38]
20 47 ms 32 ms 31 ms core-01-ge-0-2-0-0.chcg.twtelecom.net [66.192.244.40]
21 78 ms 62 ms 78 ms core-01-so-2-3-0-0.dlfw.twtelecom.net [168.215.53.46]
22 63 ms 78 ms 78 ms core-02-ge-0-2-1-3.dlfw.twtelecom.net [66.192.246.69]
23 63 ms 78 ms 78 ms dist-01-so-0-0-0-0.hsto.twtelecom.net [168.215.53.62]
24 78 ms 78 ms 78 ms 168.215.172.45
25 63 ms 62 ms 63 ms 216.54.253.2
26 63 ms 62 ms 63 ms 207.218.245.42
27 78 ms 94 ms 78 ms 69.57.146.14

Trace complete.

C:\>tracert 69.57.147.175

Tracing route to 69.57.147.175 over a maximum of 30 hops

1 <10 ms <10 ms <10 ms 10.22.2.3
2 <10 ms <10 ms <10 ms 10.22.14.5
3 <10 ms <10 ms <10 ms 10.90.248.14
4 <10 ms <10 ms <10 ms 10.90.250.90
5 <10 ms <10 ms 16 ms 10.90.250.126
6 <10 ms <10 ms <10 ms 10.90.250.157
7 16 ms 16 ms 31 ms 10.90.253.201
8 31 ms 16 ms 31 ms 10.241.7.37
9 31 ms 32 ms 31 ms 10.241.7.97
10 31 ms 31 ms 31 ms col-01-dir.msdwis.com [172.28.129.11]
11 31 ms 16 ms 31 ms fw-col-01.msdwis.com [204.115.161.61]
12 47 ms 31 ms 47 ms 4.17.247.193
13 16 ms 16 ms 31 ms fa0-0.deanwitter8.bbnplanet.net [4.17.247.98]
14 47 ms 47 ms 47 ms s5-0-4.chcgil1-cr1.bbnplanet.net [4.24.149.13]
15 31 ms 31 ms 31 ms p5-0.chcgil1-br1.bbnplanet.net [4.24.5.241]
16 31 ms 31 ms 32 ms so-3-0-0.chcgil2-br1.bbnplanet.net [4.24.9.69]
17 47 ms 31 ms 32 ms unknown.Level3.net [64.159.4.1]
18 47 ms 32 ms 46 ms gige8-0.hsipaccess1.Chicago1.Level3.net [64.159.1.222]
19 46 ms 47 ms 32 ms unknown.Level3.net [166.90.80.38]
20 32 ms 46 ms 32 ms core-01-ge-0-2-0-0.chcg.twtelecom.net [66.192.244.40]
21 63 ms 78 ms 63 ms core-01-so-2-3-0-0.dlfw.twtelecom.net [168.215.53.46]
22 78 ms 63 ms 78 ms core-02-ge-0-2-1-3.dlfw.twtelecom.net [66.192.246.69]
23 78 ms 78 ms 78 ms dist-01-so-0-0-0-0.hsto.twtelecom.net [168.215.53.62]
24 78 ms 78 ms 62 ms 168.215.172.45
25 63 ms 62 ms 63 ms 216.54.253.2
26 63 ms 62 ms 78 ms 207.218.245.42
27 78 ms 78 ms 79 ms 69.57.147.175

Trace complete.

Also, in a browser these two IPs resolve to a default Apache test page

Anyone else haviong this problem ???

 

[Un4gIvEn1]

We have had a couple reports of this on a few PCs here in our offices.

 

[Perris Calderon]

as discoverd by mosaic1

you can create an alternative location for the hosts file and use it.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\
Parameters

Look for this expandable string value
DataBasePath
The default is

%SystemRoot%\System32\drivers\etc

Change that to a new path and open a new ie

My hosts in drivers\etc was ignored.

 

[Un4gIvEn1]

this does not affect your HOSTS file. It is a change to the DNS settings on the PC.

 

[Invision]

Originally posted by Un4gIvEn1
this does not affect your HOSTS file. It is a change to the DNS settings on the PC.

True

but the process might be the same

 

[Un4gIvEn1]

This problem can be fixed by reselecting DHCP for your DNS settings. It resets the registry hive and removes the static DNS addresses. That is all you must do. I am still curious to find out where this is comming from though.

 

[Enyo]

I am currently aware of something that may be related however i have no information regarding a new exploit of this nature.

I will look into it a little more.

 

[Invision]

check this out

****************

Hijacking is a type of network security attack in which the attacker takes control of a communication - just as an airplane hijacker takes control of a flight - between two entities and masquerades as one of them. In one type of hijacking (also known as a man in the middle attack), the perpetrator takes control of an established connection while it is in progress. The attacker intercepts messages in a public key exchange and then retransmits them, substituting their own public key for the requested one, so that the two original parties still appear to be communicating with each other directly. The attacker uses a program that appears to be the server to the client and appears to be the client to the server. This attack may be used simply to gain access to the messages, or to enable the attacker to modify them before retransmitting them.
Hijacking is also used to make it appear that one or more Web sites have been taken over. There are two different types of domain name system (DNS) hijacking. In one, the attacker gains access to DNS records on a server and modifies them so that requests for the genuine Web page will be redirected elsewhere - usually to a fake page that the attacker has created. This gives the impression to the viewer that the Web site has been compromised, when in fact, only a server has been. In February 2000, an attacker hijacked RSA Security's Web site by gaining access to a DNS server that was not controlled by RSA. By modifying DNS records, the attacker diverted requests to a spoof Web site. It appeared to users that an attacker had gained access to the actual RSA Web site data and changed it - a serious problem for a security enterprise. This type of hijacking is difficult to prevent, because administrators control only their own DNS records, and have no control over upstream DNS servers. In the second type of DNS hijack, the attacker spoofs valid e-mail accounts and floods the inboxes of the technical and administrative contacts. This type of attack can be prevented by using authentication for InterNIC records.

In another type of Web site hijack, the perpetrator simply registers a domain name similar enough to a legitimate one that users are likely to type it, either by mistaking the actual name or through a typo. This type of hijack is currently being employed to send many unwary citizens to porn sites when they were attempting to visit official Web

*************

still looking into it

 

[Enyo]

The two systems rap sheets:

http://www.mynetwatchman.com/LID.asp?IID=48971313
http://www.mynetwatchman.com/LID.asp?IID=49109307

While im aware of several trojans and other malware that hijack DNS settings i am not aware of a present exploit to this end, there is nothing of this type around on the security/insecurity sites.

Please verify the systems are clean of the usual suspects. Please also note there appear to be a couple of currently undetected DDoS tools in circulation that may cause this behaviour. I suggest you check in depth systems displaying this behaviour and not rely on automated detection tools.

Traffic to DNS servers should be limited to your ISP DNS server(s) using your firewall solution.

 

[Un4gIvEn1]

I can add this. Where I work we run a very paranoid network. All of our PCs are kept within' 2 weeks of all security patches, norton is managed and running on all of our PCs and up to date. We run websense and block out as much content as we can. We do not have any unnecessary ports open. We run Lotus Notes and have outlook disabled through GPO. The only way I can see that this may have gotten on our network would be through an attachment. Our users do not have rights to be able to install files in system critical parts of the OS. None of the users have actually fessed up to opening attachments, but that would have to be the only way.

 

[Enyo]

I am not saying thats the cause. I am just thinking out loud. I would however imagine it is a binary that makes the changes rather than a OS exploit.

I have just got some new info about this.

http://article.gmane.org/gmane.comp.security.ntbugtraq/974

216.127.92.38 and 69.51.146.14

The malware makes the following registry changes as well.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\I
nter

faces\windows]

"r0x"="your s0x"

"NameServer"="69.57.146.14"



[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\I
nter

faces\{45F95E82-B443-428B-9EB7-4C65CDCD9006}]

"T2"=dword:3e057410

"LeaseTerminatesTime"=dword:3e067130

"LeaseObtainedTime"=dword:3dfe8830

"T1"=dword:3e027cb0

"NameServer"="69.57.146.14"

http://tinyurl.com/pcqf

 

[Un4gIvEn1]

I know that this much is done....

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\windows]
"r0x"="your s0x"
"NameServer"="69.57.146.14"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{45F95E82-B443-428B-9EB7-4C65CDCD9006}]
"T2"=dword:3e057410
"LeaseTerminatesTime"=dword:3e067130
"LeaseObtainedTime"=dword:3dfe8830
"T1"=dword:3e027cb0
"NameServer"="69.57.146.14"

Just curious to find out where it's comming from

 

[Un4gIvEn1]

that information was forwarded to use about 11pm last night.

 

[Enyo]

We all do, but nobody knows. This seems to have escaped us.

Process lists of any compromised systems would be handy.

 

[Enyo]

Originally posted by Un4gIvEn1
that information was forwarded to use about 11pm last night.

Yea its been on ntbugtraq for a while, ive only just seen it however.

Update:

That seems to be exactly what I have experienced. I've also run a quick port scan, nikto and nessus on the server just to try and work out what it is. Nikto showed up the default site plus some usage statistics which says the server is plain.rackshack.net ( http://69.57.146.14/usage/ ).

The server looks like a Redhat box running a host of services including a vulnerable version of SSHd.

From here

 

[Un4gIvEn1]

Man... it looks like everyone wants to know what this is. It's not a hard fix and in the whole scheme of things it's not very malicious, but it's a pain. I frequent 4 different forums and this is the first one that anyone even began talking about this. MSFN doesn't even have a thread on this yet. I guess the majority of people who are bothered by this probably don't have the smarts to fix it.

 

[X-Istence]

EV1.net is rackshack, so id have to say that someone is using Servers on rackshack's network to have users use wrong DNS entries. Email rackshack, and they could take the server offline .

 

[Enyo]

Originally posted by Un4gIvEn1
I guess the majority of people who are bothered by this probably don't have the smarts to fix it.

True, it will take time for end users to realise anything has happened, you know what they are like.

 

[Enyo]

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.

Cheers,
Russ - NTBugtraq Editor
http://news.gmane.org/gmane.comp.security.ntbugtraq

http://sarc.com/avcenter/venc/data/trojan.qhosts.html
http://vil.nai.com/vil/content/v_100719.htm

 

[Perris Calderon]

enyo, you told us about this vulnerability some time ago here

back then I told everybody let's not get caught with pants down like we did with blaster, and to ask for prompt all active x


so you were on this before it happened

shame though that it looks like dissabling active x might not even stop the execution, according to the last couple of sentences in that dialogue