What Are the 25 Best Internet Status Information Sites? SANS' Internet Storm Center (isc.sans.org) is assembling a list of the 25 web sites that provide the most useful information on the state of the Internet. For example, the Cooperative Association for Internet Data Analysis (CAIDA) has multiple projects measuring the performance ofthe Internet. Similarly, Keynote's Internet Health Report shows in near real time the latency between major backbone carriers. Sites like these help keep track of what's happening and assist incident handlers inunderstanding the full context of attacks or disruptions affecting their networks and information systems. If you have a favorite site that you regularly visit (or visit often during a major attack) and would like to recommend it for the Top 25 list, please submit it to info@sans.org with subject Top Security Status Web Sites. Please reply by Friday ifpossible. The first person to suggest each one that we decide to include at the Storm Center portal will receive a SANS shirt.

Port 554

Over the last few days we observe a small but significant increase in the
number of sources scanning port 554.

http://www.dshield.org/port_report.php?port=554&recax=1&tarax=1&srcax=2&days=10

This port is used by the "Real Time Stream Control Protocol" (rtsp). RTSP one of the protocols used to stream audio suing a 'Realserver' (Real Audio). Late last
year, a buffer overflow was found in Real Server, which can be triggered via invalid RTSP data: http://www.service.real.com/help/faq/security/bufferoverrun12192002.html . This flaw has been exploited widely in the past and an exploit has been available for several months.

Solar Flare Activity

Yet another large solar flare erupted earlier today. Like last weekend, the solar flare ejected a large amount of charged particles, which may interfere with communications later this week. For current space weather reports, see http://www.sel.noaa.gov/today.html .

There has been a very odd bit of traffic running aroud the Internet forthe past few weeks. Many have discounted it as "crud", but it looks a bitmore sinister. I need your help.

Starting Sept 29th, malformed dns queries began worldwide, from many sources. The rate and number of sources grew steadily until October 8th. At that point, the rate fell off dramatically, the signature changed, andit began to climb again. Graphs at: http://people.ists.dartmouth.edu/~gbakos/bindsweep .

This graph correlates well with data collected by DShield: http://www.dshield.org/port_report.php?port=53 (red and green line).

When one of these requests happenned to reach a nameserver, BIND 9.2.1 replied with a FORM ERR, as expected. Immediately afterwards, the prober sent a second, different dns message. This time, a broken "DDNS updatefailed". The BIND did not respond and the prober moved away.

I have traced hundreds of these back to their source address and verified that they are not spoofed. One site that I contacted was able to capture24 hours of outgoing scan traffic. Unfortunately, the hosts in question were behind a well configured firewall that did not allow replies back in. As the sniffer was placed behind that same firewall, we cannot see any complete fingerprinting sequences. It appears to use a similar decision-tree process to identify named versions, not unlike xprobe's icmp methods for OS version.

From that sniffed session, I have determined that the tool has been configured to only send scan traffic to certain /8 networks, none of which appeared on the cymru bogon list as of March, 2003. However, certain address blocks that have been returned to the IANA since then, are being scanned. Obviously, the scanner isn't terribly up to date with the globalrouting environment. There is a graph overlaying destination addresses to BGP-reachable /8 networks at: http://people.ists.dartmouth.edu/~gbakos/bindsweep

In short, the /8 destination nets are:
24-26, 43-44, 47-48, 51-54, 57, 80-82, 128-196, 198-200, 201-214, 216-222.

The compromised system was examined very briefly by someone at that site.Fport revealed to them that AOL Instant Messenger was bound to the fixedUDP source port of the outgoing scan traffic. As expected, we now know ofa format string error in aim.exe that allows arbitrary code execution. I expect that there is a controlling botnet, most likely using AIM groupchat as its channel.

A tcpdump filter that is effective in observing the initial probe is:

dst port 53 and (udp[8] = 1 and (udp[12:2] > 1000 or udp[14:2] > 1000 or udp[16:2] > 1000 or udp[18:2] > 1000 or udp[10:4] = 0))

Unfortunately, that filter only sees the initial probe, not the follow-onrefinement. I have only seen a few such exchanges. In each case, it was "DDNS Update Failed" message with a ID# of 1409. The filter to see this traffic is:

dst port 53 and udp[8:2] = 1409 and udp[10] >> 3 = 0x15 and udp[11] &; 0x0f != 0

If any of you see this leaving your network, please inform the owner of it that it is compromised, and (with their permission) start capturing ALL traffic to and from that box, regardless of protocol/port.

Please contact me if you have or need additional information.

---------------------------------------------------------------------------
George Bakos, ISTS -- contact: ISC _AT_ SANS.ORG

Large number of Windows Updates

Today, Microsoft published a number of advisories, 5 of which are classified as 'critical' (= allow remote execution of code). For a summary, see:
http://www.microsoft.com//technet/security/bulletin/winoct03.asp

Essentially all currently supported versions of Windows are affected.

The release of such a large number of vulnerabilities is due to Microsoft's implementation of a new "Security Bulletin Release Process". New security bulletins will now be released monthly. For details, see: http://www.microsoft.com/technet/security/bulletin/revsbwp.asp
Windows RCP race condition

for a few days, a possible new RPC DCOM vulnerability has been discussed on a number of vulnerability lists. Exploit code has been posted, but it is not widely accepted that this code exploits a new RPC vulnerability in order to obtain a remote shell. However, according to an ISS XForce advisory, a denial of service condition is possible even if the system is fully patched.

Recommendation:

* All Windows systems have to be fully patched. The new exploit may still work according to some reports. However, patching a system will prevent the older exploits and it will likely ease installation of any new patches.

* DCOM RPC should be disabled if possible.

* apply firewalls to prevent connections to vulnerable systems. Note that other vectors then the widely reported port 135 may exist. Apply firewall rules in accordance with local security policies. Some applications may require the use of RPC DCOM to communicate with remote systems. Consider moving these functions to a VPN.

Randex.Q

We have received reports of infections with the Randex.Q virus. This virus will spread via unprotected file shares or file shares with weak administrator password. Infected machines will connect to an IRC server to receive various commands.

Workaround: Current virus scanner signatures will recognize this virus. Do not connect systems with file sharing enabled to public networks. This virus can enter protected networks via mobile systems. Use strong passwords internally and consider establishing a procedure to scan external computers (e.g. laptops) before connecting them to the internal network.

This is a first "Incidents Report". We hope to publish more such reports in the future, and are looking for contributions. Feedback is welcome. Please send to 'isc_AT_sans.org'. If you wish to discus this report, please post your comments to the intrusions list ( http://www.sans.org/intrusions ).

Incidents Reports: http://isc.sans.org/webexploit.pdf

(if you are using xpdf and don't see some of the text, try 'acroread' to view the PDF file)

Summary:
On September 30th, the OpenSSL group released a security advisory about vulnerabilities in the SSL code, that may cause a DoS (Denial of Service) and, possibly, remote compromise.

The vulnerabilities includes a flaw in the OpenSSL implementation of the Abstract Syntax Notation One (ASN.1) data format and also an unsual, but possible, exploitation of the code that verifies the certificates, that may result a DoS attack.

All versions up to and including 0.9.6j and 0.9.7b are affected. Also, all versions of SSLeay are known to be affected, as well.

Solution:
Upgrade to the recent released versions: 0.9.6k or 0.9.7c. However, the openssl libraries can be loaded dynamically or they may be compiled statically into the respective binary. For dynamically loaded libraries, the openssl library update is sufficient. Statically linked programs have to be recompiled. To check which libraries are loadded dynamically, use the 'ldd' command.
References:
OpenSSL Security Advisory:

http://www.openssl.org/news/secadv_20030930.txt

Fixed OpenSSL Versions:

- Version: 0.9.6k: http://www.openssl.org/source/openssl-0.9.6k.tar.gz

- Version: 0.9.7c: http://www.openssl.org/source/openssl-0.9.7c.tar.gz

The major linux distributions are announcing new OpenSSL packages to correct the issues.

__________________________________

Send comments to isc _AT_ sans.org

**** UPDATE ****
The odd DNS issues are likely caused by the QHosts-1 Trojan. For details see:

http://us.mcafee.com/virusInfo/default.asp?id=description&;virus_k=100719

http://vil.nai.com/vil/content/v_100719.htm
********
As initially posted to the SANS intrustions list, some sites observe an increase
in abnormal DNS queries. For the original post, see
http://cert.uni-stuttgart.de/archive/intrusions/2003/10/msg00003.html

A likely related issue has been reported to NT Bugtraq:
http://www.ntbugtraq.com/default.asp?pid=36sid=12A2=ind0310&L=ntbugtraq&D=0&F=P&P=1048

Here, a user reported that "Various Windows 2000 professional workstations are changing the DNS servers they are configured to use". The new DNS server, 216.127.92.38 and 69.57.146.14, is hosted by 'Everyone's Internet Inc.', (ev1.com).

This user did report suspicous changes to the registry:

[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"
for more details, see this NT Bugtraq post:
http://www.ntbugtraq.com/default.asp?pid=36&sid=1&A2=ind0310&L=ntbugtraq&D=0&F=P&P=1879
------

If you would like to share any related logs, please send them to isc_AT_sans.org