The below was sent to us as well as some of the ISACs around the net tonight. As there is quite a bit of information being conveyed by the author, I am going to leave the majority of the advisory as originally written.  I will note that this started with a click happy user on AIM to the best of our knowledge.

---snip---
A bot was seen spreading via AOL Instant Messenger (AIM) earlier today that appears to be using "encrypted"[1] peer-to-peer (P2P - possibly Waste?) as the Command and Control (C&C) mechanism. The bots communicate with each other via port 8/TCP.

The bot does not use DNS to find any C&C. It also does not use any human readable strings in its client/server communication. Therefore, many IDS measures will not help you detect infected hosts on your network. Flow analysis and/or tcpdump looking for mysterious port 8/TCP traffic seems to be the best way to detect these infections on your network.

I realize that phatbot has been able to use Waste as the C&C for several years. However, I remember finding these botnets years ago, and the bots involved, and they typically were 600KB or more in size. The bot involved here is comparatively lean at 173KB.

Info about the sample I obtained:
MD5: 74600e5bc19538a3b6a0b4086f4e0053
Installation Location (when run): %WINDIR%\System32\mstc.exe
WinXP Firewall: Grants itself an exception called "null", which allows inbound 8/tcp from anywhere. This was done without the user notification pop-up (it likely edited the registry entry directly).

The file distributed via the AIM link and %WINDIR%\System32\mstc.exe are identical - no other files are dropped, etc.

I infected a test computer with the binary. It tried to connect to port 8/tcp on 22 different IP addresses. (Note that these are most likely the "seeds" of the P2P network that were coded into the version of the binary that I downloaded.) Only four of the IP addresses responded that they were listening on 8/tcp.

My lab computer tried to contact each of the 22 IP addresses many times (I left it infected for about 15 minutes with a firewall in place that blocked all incoming packets, solicited or otherwise). Since it tried to contact each of these many times, and not any other IP addresses, I feel it is fairly safe to guess it was not randomly selecting IPs to obscure "the real C&Cs".

Anyhow, after 15 minutes of firewalling off all inbound packets altogether (even SYN/ACKs) to my infected lab computer, I lifted the incoming IP restriction. The first host my lab computer connected to on 8/tcp started a relatively short connection (10-12 packets each way), and nothing was in cleartext. In the middle of the TCP conversation, that same host connected to port 8/tcp on my host (the malware holds that port open). The connection from them to me was simply a three-way handshake, immediately followed by FIN/ACKs from them  then me. It then closed my connection to it altogether, via FIN/ACKs again.

My host then tried several other IPs (still in the list of 22, with only four of them online), and this time, connected successfully to a different host. The connection lasted for a couple of minutes before I pulled the plug.

There was more communication this time around. During the connection, the remote host connected to 8/tcp on me just like the other one did (three-way handshake, then FIN/ACK, just like before). The initial connection from  my host to theirs continued afterward. One of the packets from the remote host contained a full 1460 bytes of data. (Other packets to/from 8/tcp on infected hosts thus far had contained 64 bytes of data or less.) There was no SSL/TLS negotiation evident, and again, the contents were not human readable. I haven't taken the time yet to see if it's something simple like XOR or Base64. I suspect the content was an updated list of other infected hosts.

While still connected to that host, my bot still tried connecting to others (not common for a traditional botnet, but expected for a P2P connection). It connected successfully to a third host. My host did to that host as the others above did to it - complete the three-way handshake, then ended it with FIN ACKs. It then connected to another host that was NOT on the initial seed list. (My theory is that my host learned of this one from another bot) After that, I turned it off, so that I could write this.

Moral of the story: Prepare to watch for 8/tcp flows for a while. Unless I'm wrong, this botnet should be able to stick around for a while.

[1] I am using "encrypted" in quotes because I have not identified the protocol - but it is not human-readable. I'm sorry if this sounds FUD-like, but I wanted to get the word out sometime *before* I had done hours of analysis!
-------Snip-------

Update 1:

Earlier Sunday, Symantec has posted a write-up about this particular binary.  It is located at http://www.sarc.com/avcenter/venc/data/w32.nugache.a@mm.html. Please note that they do not have any mention about the P2P traffic noted above.  There is more analysis being done on malware by the various AV companies and others in our malware analysis team.

I expect that this binary will be detected by most AV companies quickly (today I hope) and slow its spread tremendously.  However, I also expect that this is a signal that the botnet writers are entering a new generation of  development and capabilities.  Those of us that are tasked with defending our various networks will need to find a new and better game plan to spot and counter these encrypted/p2p based botnets.

--
Scott Fendley
Handler on Duty

If you are on the receiving end of a bot-net that insists on trying to relay spam through your mail gateway, your systems can get into trouble even though relaying is blocked.  A reader wrote in earlier today with his mail gateway under full load only from rejecting the relay attempts. Source IP addrs kept changing, and only by continuously adapting his firewall filters was he able to bring the load down to about one spam relay attempt per second still reaching the email gateway. 

If you are idly bored at the moment, it might be a good time to read up on your firewall's layer-7 filtering capability for SMTP. Chances are there's features in your firewall that can help to off-load relay attacks from the mail system onto the firewall. Of course, if you end up with a D.o.S on the latter, that doesn't accomplish much, either :-)

Update 21:17UTC:  A number of comments indicate that BSD "spamd" seems to be a popular measure used to thwart such relay floods. This sample chapter of "Building Firewalls with OpenBSD" describes how it can be done. Another good description can be found on http://www.openbsd.org/papers/bsdcan05-spamd/  (Thanks, Navan!)
Folks using Postfix might want to take a look at Postgrey, a grey-listing implementation that is apparently also quite effective in squelching crud.

Disclaimers:
Note that no one is claiming the activity below is malicious or illegal.  Visit the urls at your own risk. They are being posted because they don't appear to be malicious in nature.

One of our readers has come across an interesting phenomenon in his proxy logs that we're hoping someone can shed some light on.  Its not necessarily malicious, its just hinkey.

Imagine reviewing your webserver or proxy logs and seeing requests for a website completely unrelated to your organization, but an IP address in your address block appears in the hostname.

(Thanks to Jeremy for the report and the offer to share. I was able to find plenty of examples on the internet without referencing yours specifically)

So here is an example URL that might show up in your logs:

http://check.216.109.136.53.v.80.pw1.super.proxy.scanner.i.thu.cn/Provy_OK.html

running the host command on the above hostname provides:

check.216.109.136.53.v.80.pw1.super.proxy.scanner.i.thu.cn has address 61.135.170.153

Hrm. 216.109.136.53 is a an IP in Hoboken, NJ. Thats about 6800 miles away from the host in China (61.135.170.153).

If you search for the string "super.proxy.scanner" in google you get 3 pages of proxy and web logs showing requests for various URLs that follow the form:

http://check.$ip_address.v.80.(pdx8|PCN22|mt1|pw1).super.proxy.scanner.(i.thu.cn|ii.9966.org)/Provy_OK.html

All of the hostnames resolve to 61.135.170.153.  All of the logs I could find show this activity only in the March-April 2006 timeframe so relatively new.

Visiting one of these hinkey URLs always provides the following (well at least in the few I tried):

"OK0001"

The webserver is running lighttpd/1.4.11 (http://www.lighttpd.net/)

Thats about all I could find. The string "super.proxy.scanner" showed up on a few sites as the top search results so someone or some program is looking for this traffic as well.

So let us know if you have any theories (or maybe you know exactly whats going on here).  Also if you have any web/proxy log entries (or even better pcaps of all traffic related to one of these IPs) feel free to send them in.  We'll post whatever we find in the diary.

One interesting tidbit, while researching this I fat-fingered a lookup and the DNS server gave me an interesting IP back:

dig any suprt.proxy.scanner.ii.9966.org
;; QUESTION SECTION:
;suprt.proxy.scanner.ii.9966.org. IN    ANY

;; ANSWER SECTION:
suprt.proxy.scanner.ii.9966.org. 300 IN A       61.135.170.153
suprt.proxy.scanner.ii.9966.org. 300 IN NS      ns1.suprt.proxy.scanner.ii.9966.org.
suprt.proxy.scanner.ii.9966.org. 300 IN NS      ns2.suprt.proxy.scanner.ii.9966.org.

;; AUTHORITY SECTION:
suprt.proxy.scanner.ii.9966.org. 300 IN NS      ns2.suprt.proxy.scanner.ii.9966.org.
suprt.proxy.scanner.ii.9966.org. 300 IN NS      ns1.suprt.proxy.scanner.ii.9966.org.

;; ADDITIONAL SECTION:
ns1.suprt.proxy.scanner.ii.9966.org. 300 IN A   61.135.170.159
ns2.suprt.proxy.scanner.ii.9966.org. 300 IN A   61.135.159.152

Here is what I would have gotten without my typo:
dig any super.proxy.scanner.ii.9966.org
;; QUESTION SECTION:
;super.proxy.scanner.ii.9966.org. IN    ANY

;; ANSWER SECTION:
super.proxy.scanner.ii.9966.org. 300 IN A       61.135.170.153

;; AUTHORITY SECTION:
ii.9966.org.            86400   IN      NS      ns2.ii.9966.org.
ii.9966.org.            86400   IN      NS      ns1.ii.9966.org.

Some results from google:
check.216.109.136.53.v.80.pdx8.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.216.109.136.53.v.80.pw1.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.216.109.136.53.v.80.PCN22.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.63.245.201.35.v.80.mt1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.66.34.248.90.v.80.pcn22.super.proxy.scanner.ii.9966.org/Provy_OK.html     
check.147.251.3.78.v.80.PCN22.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.147.251.3.39.v.80.PCN22.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.130.71.96.35.v.80.mt1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.141.225.152.87.v.80.pdx8.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.207.73.173.23.v.80.pdx8.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.63.245.201.36.v.80.pw1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.207.73.173.23.v.80.pdx8.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.58.188.232.10.v.80.PCN22.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.63.245.201.35.v.80.PCN22.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.207.210.74.70.v.80.pdx8.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.151.100.18.65.v.80.PCN22.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.212.192.114.3.v.80.mt1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.128.243.107.6.v.8080.PCN22.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.192.107.81.22.v.80.pw1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.192.107.81.22.v.80.PCN22.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.130.85.162.106.v.80.pw1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.130.85.162.106.v.80.pw1.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.167.196.204.113.v.80.pdx8.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.212.192.114.3.v.80.mt1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.207.210.74.70.v.80.pdx8.super.proxy.scanner.ii.9966.or

Interesting entry from the web log for a webcam:

Camera 1: Security alert:
user from IP address: 61.135.170.159 is trying to read file:
check.70.60.215.15.v.8080.PCN22.super.proxy.scanner.i.thu.cn/Provy_OK.html

Robert - SANS ISC Handler on Duty

Juniper Networks released a vulnerability announcement today.
From: http://www.juniper.net/support/security/alerts/PSN-2006-03-013.txt
"Title: IVE ActiveX client vulnerability
Date: 25 April 2006
Version: 1.0
Impact: Client side code execution in context of Internet Explorer
Affected Products: IVE OS 1.x to 5.x
Max Risk: High
Recommended Actions: Upgrade the IVE software to any of the following fixed versions: 5.3r2.1, 5.2r4.1, 5.1r8, 5.0r6.1, 4.2r8.1"

It appears that an activeX control that is installed when using IVE can be remotely exploited.
The exploit described by eeye looks fairly trivial.

IVE is  Instant Virtual Extranet which provides SSL VPN control with centralized reporting, monitoring and configuration management. It is basically a host security auditor and can be used as an element of their netscreen remote client. It can verify things like recent virus signatures and scans. Which  is important before letting some machine on to your corporate network!

eeye has published the details here:
http://www.eeye.com/html/research/advisories/AD20060424.html

Yesterday's.
Today's.

#!/bin/sh
cat /usr/home/tliston/diaryheader.html > diary.html
echo "$1 has discovered a vulnerability in Internet Explorer," >> diary.html
echo "which can be exploited by $2 to compromise a user's system." >> diary.html
echo "The vulnerability is caused by an error in $3 " >> diary.html
echo "that can be exploited to $4, by tricking a user into visiting" >> diary.html 
echo " a malicious web site. Successful exploitation allows $5." >> diary.html
cat /usr/home/tliston/diaryfooter.html >> diary.html
mv diary.html /www/htdocs

tommy: tom$: ./ie_dujour.sh
MATTHEW MURPHY has discovered a vulnerability in Internet Explorer, which can be exploited by EVIL HACKERS to compromise a user's system. The vulnerability is caused by an error in A RACE CONDITION IN THE DISPLAY AND PROCESSING OF SECURITY DIALOGS RELATING TO THE INSTALLATION/EXECUTION OF ACTIVEX CONTROLS that can be exploited to CONVINCE A USER TO INSTALL A MALICIOUS ACTIVEX COMPONENT, by tricking a user into visiting a malicious website.  Successful exploitation allows THE ABILITY TO EXECUTE ARBITRARY CODE ON THE TARGET MACHINE.

Sigh...

Handler on Duty: Tom Liston - Intelguardians

I was sitting next to Ed Skoudis in the front row of the Anti-Spyware Coalition Workshop in Washington, D.C. this past February 9th.  Ed and I had been working together during the previous days, testing enterprise anti-spyware applications for a "shootout" article that we were co-authoring for Information Security magazine.  In preparing the various tests for that article, I had developed 25 small applications that each performed a single "spyware-like" behavior - dropping an executable and installing a key in the Windows registry to launch it on boot, changing the user's wallpaper, changing the user's homepage, etc...

Ed was scheduled to speak on one of the many panels that presented that day, and right before he took the stage, he turned to me and said, "Whatever I say, just go with it..."  

More frightening words have seldom been uttered.

When Ed's turn to speak came, he stood before an assembly of several hundred lawmakers, policy professionals, and anti-spyware vendors and asked a simple question: by a show of hands, how many in the audience were "spyware authors"?

"Come on," he continued, "I know that there is at least SOMEONE here who has written spyware."

Then he turned and stared at me.

Thanks, Ed.

Hello.  My name is Tom, and I'm a spyware author.

Unlike the truly Evil spyware authors who want to steal your private information or monitor your surfing habits, I'm here to help.  The 25 mini spyware-like applications that I wrote are designed to test the effectiveness of your anti-spyware solution at detecting and alerting you to behaviors that can indicate that software may not be on the up-and-up.  While most anti-spyware applications have some signature based capabilities, as the spyware menace grows, behavior based detection and blocking are a must.

The suite of test applications will be released in conjunction with our article on May 1st, and is dubbed SPYCAR -- an homage to the European Institute for Computer Antivirus Research (EICAR) antivirus test file.  While it won't be available until May 1st, SPYCAR will be located here.

Tom Liston
Intelguardians

Reader JD mentions that today is the anniversary of Chernobyl... both the Nucular (sic) disaster from 1986 and the flash-garbage-into-your-BIOS virus from 1999.  I guess that's sort of an indication of how geeky you are.  When I saw the news headline mentioning Chernobyl, my first though was of the virus.  Our condolences to those impacted even to this day by the worst nuclear accident in history.

But, JD (who referred to yours truly as a post-hog ;) mentioned that it was this virus (also known as CIH) that got him involved with malware research in the first place.  Blowing away the BIOS rendered many systems in 1999 totally unusable resulting in a devastating infection.  It was indeed a watershed event for a lot of us in the handlerati.  JD asks for other readers who were significantly impacted by CIH to share their recollections of that event.  Got any interesting CIH stories that you care to share?

--Ed.
Intelguardians

UPDATE: Reader John Smith recalls wistfully:

"I remember that day, April 26th 1999. It was Monday. Since April 27th is a national holiday here in Slovenia (Day of Uprising against the Occupation), almost everyone took a day off and enjoyed a 4-day weekend. And schools were closed.  High school classmate, who worked in a bakery, called me sometime around 11h. He had a major problem with computers - one of the accountants came to work to finish some monthly report and every computer she turned on started to boot Windows, then went crazy. It simply did not start, if turned off and on, it was even worse - Windows did not boot. So she went around the office and started all other computers. And guess what, all 10 of them failed to work.

By starting the computers, when first CIH infected program started, junk data was written to the beginning of hard drives. Fortunately, the motherboards on those computers were not damaged.  He brought one computer to me and after some DiskEdit exploration, I discovered that FAT2 was intact. So I copied FAT2 to FAT1 and
re-calculated the master boot sector. After booting from floppy and disinfecting the files with F-PROT, computer was operational again. We were lucky and we managed to rescue data from all computers.

BTW, I wonder what CIH author Chen Ing-Hau is doing these days. Is he reading this?"

I wonder too....  By the way, is it just me, or did anyone else notice that if you Base-64 encode "Chen Ing-Hau" and then ROT-14 it, and XOR it with "Intelguardians", it actually spells "Ekim Roop"?  Maybe it's just me. --Ed Skoudis.

In a somewhat related story, ZDNet has an interesting article that discusses the fact that Microsoft has decided that the Windows Vista firewall will include no outbound filtering by default.  Apparently, Microsoft was considering blocking outbound connections by default, but, in response to large enterprise customer requests, they won't be doing that.  Not breaking corporate apps is more important than security, I suppose is the reasoning.  This is a change from the original Plan (yes, note the capital P), which said that Vista would ship with a two-way firewall.  It still has that capability, but outbound filtering will be turned off by default.

I remember a recent fascinating rant from Marcus Ranum, saying (I paraphrase) that a firewall that doesn't block outbound traffic isn't worthy of the name firewall.  From the guy who popularized the term firewall so long ago (and the term script kiddie), that's an interesting point.

But, of course, the lack of outbound filtering isn't a problem, given that the client-side apps are so rock solid.  Also, with your Jedi-like Windows command-line Kung Fu, it won't matter if your box gets hit, because you'll be able to figure it out so quickly and respond...  Yeah, right!

To be fair, there are some arguments for not doing outbound filtering on a personal firewall.  I don't agree with them, but the arguments do exist.

Thanks to reader Tony van der Togt for the heads-up on the ZDNet article.

--Ed Skoudis.
Intelguardians.

UPDATE: Our readers are the best!  It seems that we have eyes everywhere.  Chris Gurley, one of said readers, told us that he was at a Microsoft Security Summit yesterday in Dallas, TX.  He said that a Microsoft security guru at this meeting mentioned that they still intend on shipping Vista with the outbound firewall filtering activated by default.  So, the ZDNet article may be incorrect.  We don't have an authoritative word on The Plan here... but we want to give you all the info we have.  This one will be interesting!

Today, if you are plagued with farcical fulminations from Firefox fans or self-satisfied smirks from Safari sympathizers, it may be because of this, from Secunia:

"Michal Zalewski has discovered a vulnerability in Internet Explorer, which can be exploited by malicious people to compromise a user's system.  The vulnerability is caused due to an error in the processing of certain sequences of nested 'object' HTML tags. This can be exploited to corrupt memory by tricking a user into visiting a malicious web site.  Successful exploitation allows execution of arbitrary code."

Thanks to diligent reader Karl Prince for the heads-up.

I remember back in the mid-90's, we used to joke about a bug-of-the-month club for Sendmail.  Well, Sendmail has gotten far better, but perhaps we need a bug-of-the-week club, or even a zero-day-of-the-week (ZDotW) club for IE?

--Ed Skoudis
Intelguardians.

Lots of folks have sent us e-mail wondering why their WinXP boxen have suddenly indicated that they have a new patch.  It is this update that fellow handler Toby Kohlenberg mentioned a couple days ago, which has now been pushed.  Look here for details.

In other Windows-patching news, Microsoft has also released a completely separate patch to fix an error associated with KB900485, which fixes, and I quote:

"Date last published: 4/25/2006
Install this update to prevent an issue in which you may receive a 'stop 0x7e in AEC.SYS' error message on a computer that is running Windows XP Service Pack 2.  The error may occur during startup, or after the system has started.  AEC.SYS is the acoustic echo canceling driver.  After you install this item, you may have to restart your computer."

Microsoft has told us that this patch is associated with the following:

"This is the ACE reliability update.   It has been available via download center for several months; when people do hit the crash the Watson/OCA site refers them to the download.  For non-security updates, especially things like this reliability update, we do try to have them posted on www.microsoft.com/downloads and available through Watson/OCA or other means for some period of time before pushing out through WU. This gives us additional confidence in the quality of the update before pushing out to several hundred million users.

This specific fix is a random timing bugcheck that can happen when using two-way audio (e.g. netmeeting, messenger, etc.)  It is a random event that could happen at any time.  If you hit it, and reboot, you might not ever hit it again; or you might hit it next month, or in a few months, or the next day.

We monitor the Watson/OCA crash data, and when we have a higher-volume hit in a Windows component that we can fix, we do so, and post it on download center.  Over time, we then move the higher-volume cases to Windows Update. This is just one such case.  Installing this update helps prevent people from crashing in the future."

Interesting insights into how things work inside the magic curtain.  Thanks, Microsoft!
--Ed Skoudis
Intelguardians.

NISCC has published an advisory about a potential DNS vulnerability today: http://www.niscc.gov.uk/niscc/docs/br-20060425-00311.html

These issues were discovered by use of the Oulu University Secure Programming Group's new PROTOS test-suite c09-dns. This tool is not currently public.

Their abstract (aka description) states:
"Abstract: The vulnerabilities described in this advisory affect implementations of the Domain Name System (DNS) protocol. Many vendors include support for this protocol in their products and may be impacted to varying degrees, if at all. "

Notice they state "affect implementations" which implies it is not a vulnerability in the basic DNS protocol rather it is an issue in how some of the vendors implemented that protocol.

This link has a list of vendors who have responded with vulnerability information so far. http://www.niscc.gov.uk/niscc/docs/re-20060425-00312.pdf?lang=en 

Not many vendors provided vulnerability details on their products.

The Internet Software Consortium (http://isc.org/) authors of (BIND) provided a detailed response. Juniper Networks (http://www.juniper.net/), Delegate (http://www.delegate.org/) and pdnsd (http://www.phys.uu.ne/~rombouts/ )also provided specific details. In each case the impact appears to be DOS not a remote code execution. 

Hitachi and Wind River state that they believe they are not vulnerable.

Microsoft, Sun and Ethereal all reported that they are reviewing or testing for these issues.

 

PATCHES
ISC (BIND), MyDNS, Juniper Networks, pdnsd all announced vulnerabilities.
All but ISC have released patches or upgrades for them.

ISC has not released a patch but based on their analysis their vulnerability is a very low risk. Its appears to be based on an malformed 2nd tsig packet. If you understand tsig you understand why this should not be much of a threat as they have already established a trust relationship.

The pdnsd maintainer, Paul A Rombouts,  recommends upgrading to version 1.2.4 or later of pdnsd. http://www.phys.uu.nl/~rombouts/pdnsd.html
 

MyDNS 1.1.0 has a fix for a "query-of-death" DOS and can be found here: http://mydns.bboy.net

Juniper Networks has several upgrade options for their e-series routers which are the only routers mentioned as having a vulnerability. You may need a Juniper networks account to get access to those updates. According to the vendor document above  "The issue was resolved in the following JUNOSeupdates: 5-3-5p0-2, 6-0-3p0-6, 6-0-4, 6-1-3p0-1, 7-0-1p0-7, 7-0-2, 7-1-0p0-1, 7-1-1. Later JUNOSe releases are unaffected."

UPDATE:

We received a nice tip about this one from Koivunen Toni, of CERT-FI...
Solution:
---> Looks like it is a scan for backdoored pr0n websites...

bellow is another sample:

http://aaaaaaaaa.com/autorank/control.php
Accept-H33p3r:<<unix-command>>
http://bbbbbbbbb.com/images/nav.php
Accept-H33p3r:<<unix-command>>
http://xxxxxxxxx.com/cgi-bin/archives/00000155_.cgi
Accept-Ip:<<unix-command>>
http://yyyyyyyyy.net/cgi-bin/system.pl
Xa=Xa;g=<<unix-command>>;exit
http://wwwwwwwww.com/cgi-bin/pennywize/penny.cgi
Accept-Ip:<<unix-command>>
http://zzzzzzzzz.com/cgi-bin/tgsw/de/teens/control.cgi
Xa=Xa;g=<<unix-command>>;exit
http://ttttttttt.com/abicons/apache/small/icon.php
Accept-H33p3r:<<unix-command>>

-----------------------------------------------------------
Today we got an interesting email...it was reporting a strange http request:

--------------------------------------------------------------------------------
POST /thumbs/index.php HTTP/1.1
Host: example.com

Connection: keep-alive
Content-Length: 0
Cookie: cat /etc/passwd
Referer: http://example.com/thumbs/index.php
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Pragma: no-cache
Cache-Control: no-cache
accept_language: cat /etc/passwd
accept_ip: cat /etc/passwd
ip: cat /etc/passwd
accept_whynot: cat /etc/passwd
accept_phpinfo: cat /etc/passwd
accept_redlight: cat /etc/passwd
accept_ASE: cat /etc/passwd
accept_X: cat /etc/passwd
USER_X87NEK: cat /etc/passwd
ACCEPT_HHT: cat /etc/passwd
Accept_MUZZ: cat /etc/passwd
Accept_MusicIsTheKey: cat /etc/passwd
Accept_encoding: cat /etc/passwd
Accept_MS: cat /etc/passwd
ACCEPT_SHREK: cat /etc/passwd
ACCEPT_s1yntr1o: cat /etc/passwd
ACCEPT_shockfx: cat /etc/passwd
ACCEPT_COOLHK: cat /etc/passwd
ACCEPT_l0ve: cat /etc/passwd
Morgoth: cat /etc/passwd
ACCEPT_ShAd0w: cat /etc/passwd
ACCEPT_bk4712: cat /etc/passwd
Accept_BBBS: cat /etc/passwd
ACCEPT_Resys: cat /etc/passwd
ACCEPT_XPW: cat /etc/passwd
BC: cat /etc/passwd
ZION: cat /etc/passwd
cmd: cat /etc/passwd
ACCEPT_netsploiter: cat /etc/passwd
ACCEPT_jayman: cat /etc/passwd
ACCEPT_Joschi: cat /etc/passwd
ACCEPT_MechW: cat /etc/passwd
ACCEPT_slickrick: cat /etc/passwd
ACCEPT_Banana: cat /etc/passwd
ACCEPT_H33p3r: cat /etc/passwd
ACCEPT_KaIzeR: cat /etc/passwd
ACCEPT_Joschi: cat /etc/passwd
Content-type: application/x-www-form-urlencoded
-----------------------------------------------------------------------

While this is a 'strange' http request, we believe that nothing on the 'cat /etc/passwd' part would be done on the webserver side...
So, our request is to know if have you ever seen this before...
---------------------------------------------------------------
Handler on Duty: Pedro Bueno ( pbueno //&&// isc. sans. org)

David Haltinner asked what other ISC readers are doing in terms of looking for, complying with, auditing for, etc... PCI requirements.
Do any of you have stories about the costs, benefits, positives and/or negatives of working with this standard?

For those of you not familiar with it, here's a place to start reading:
http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp_merchants.html

Microsoft recently released a link to help you choose "good passwords"
http://www.microsoft.com/athome/security/privacy/password_checker.mspx

In my opinion they did some things good and some things bad.

BAD teaching people to type their password into a website is not a good idea.
It violates most corporation's security policies.

GOOD it's a java applet that appears to run locally so your password is never sent over the internet. This could change at anytime so I would not recommend you type your password into it.

BAD the Java applet doesn't appear to check for repeated chars and other weak passwords generation tricks. It determines the strength based solely on the mix of char sets and the length of password. It appears they use four sets of characters:
Numbers, lower case letters, upper case letters and special.
alpha = [ a-z ]
UPPER = [ A-Z ]
num = [ 0-9 ]
special = not [ alpha | UPPER | num ]

GOOD They didn't include a dictionary or brute force lookup tool.
There are plenty of them on the net and inclusion would have meant downloading huge dictionaries or sending the password to a system on the net for testing. If Microsoft has compiled a dictionary with a high rate for passwords I don't want them to publish it!
My personal recommendation for dictionary or brute force password checking is to do it on a STANDALONE system and protect the output at the highest level of any data in your corporation.

GOOD their suggestions here are good.
http://www.microsoft.com/athome/security/privacy/password.mspx

This appears to be the basic pattern for this java password testing tool.
Any combination of chars from JUST one of these sets (UPPER, alpha, num, special) is weak.
7 or less chars from any mixture of sets is weak.
7 or more of one set plus one from a different set is medium.
8 chars with at least one element from 3 different sets is strong.
14 chars or more with at least one element from at least 3 of the sets is best.
Even if that's 12 a's, 1, and ! (shifted 1).

My recommendations: Don't use the Microsoft java password testing tool or anyone's online password testing tool. Choose good passwords. Microsoft's recommendations for choosing good passwords is pretty good.

Recall end of last year where we have posted a story on security and abuse email to be updated and contactable especially during holiday season.

One of our reader wrote to us about RFC 3013 on '/security' URL on websites (e.g. www.somedomain.com/security).

Under RFC 3013, it is stated that ISPs may consider using common URLs for security and abuse information (e.g. http://www.ISP-name-here.net/security/).

However,unlike RFC 2142 on email contact, this is not widely adopted. It will be of great convenience to everyone if every website is to follow and maintain a '/security' link.

Three vulnerabilities were reported in Symantec Scan Engine. The vulnerabilities could allow a remote user to access the scan engine, download any file located under the Symantec Scan Engine installation directory and conduct man-in-the-middle attacks. Symantec Scan Engine is used in third party applications to interface with Symantec content scanning technologies.

The first vulnerability is the authentication mechanism used by Symantec Scan Engine over its web-based administrative interface. The Scan Engine does not properly authenticate web-based user logins which will then allow a remote user to bypass authentication and gain control of the Scan Engine server.

The second vulnerability allows an unauthenticated remote user to send a specially crafted HTTP request to access arbitrary files located under the Symantec Scan Engine installation directory.

The third vulnerability is the result of the Scan Engine using a static private DSA key for SSL communications. The key cannot be changed by end users and can be extracted from any installation of the product. As a result, this could allow a remote user to conduct man-in-the-middle attacks.

The vulnerabilities were reported by Rapid7 and PoC has been published to demonstrate the first vulnerability.

Symantec has released fixes to the latest product.

Symantec Advisory
http://www.rapid7.com/advisories/R7-0021.html
http://www.rapid7.com/advisories/R7-0022.html
http://www.rapid7.com/advisories/R7-0023.html
http://www.frsirt.com/english/advisories/2006/1464

Multiple vulnerabilities have been reported in Apple Mac OS X and applications. Proof of Concept code has already been posted along with the information regarding the vulnerabilities. At this time no patches or workarounds appear to be available for the majority of the vulnerabilities. The impact is Denial of Service or arbitrary code executed remotely, and severity is highly critical.

Links to advisories:

Apple OS X 10.4.5 .tiff "LZWDecodeVector ()" Heap Overflow
http://www.security-protocols.com/sp-x24-advisory.php

Apple OS X BOM ArchiveHelper .zip Heap Overflow
http://www.security-protocols.com/sp-x25-advisory.php

Apple OS X Safari 2.0.3 Multiple Vulnerabilities
http://www.security-protocols.com/sp-x26-advisory.php

Apple OS X 10.4.6 "ReadBMP ()" .bmp Heap Overflow
http://www.security-protocols.com/sp-x27-advisory.php

Apple OS X 10.4.6 "CFAllocatorAllocate ()" .gif Heap Overflow
http://www.security-protocols.com/sp-x28-advisory.php

Apple OS X 10.4.6 .tiff "_cg_TIFFSetField ()" DoS
http://www.security-protocols.com/sp-x29-advisory.php

Apple OS X 10.4.6 .tiff "PredictorVSetField ()" Heap Overflow
http://www.security-protocols.com/sp-x30-advisory.php

Cheers,
Adrien

There have been reports of problems with Microsoft patch MS06-013 Cumulative Security Update for Internet Explorer (912812). MS06-016 where the Outlook Express address book disappears. In this case removal of the patch and the address book re-appears, however the other vulnerabilities the patch address come back.

One other Microsoft patch MS06-015 will be updated due to compatibility issues. This was announced in their blog.  http://blogs.technet.com/msrc/archive/2006/04/21/425838.aspx

If you have any issues with a Microsoft patch impacting your system contact them directly, the call is free. In the US or Canada dial: 1-866 - 727 - 2389 ( 866 PC SAFETY ) In other countries/regions, contact your local Microsoft office.

Cheers,
Adrien

John at nist.org pointed out that a jurisdiction in the state of New York (United States) is mandating security requirements where wireless networking is used. Sounds like a good thing, right? The thing that perplexes me is that they stop at requiring that the SSID be changed, OR that a firewall be installed. There doesn't appear to be any mention of one of the primary protection methods for wireless, namely encryption. If you wish to secure wireless you should use authentication (preferably strong), and encrypt transmissions. Changing or disabling SSID broadcasts is essentially useless, it can be guessed or sniffed. If the threat they are attempting to mitigate is identity theft of data being passed in the clear 'through the air' encryption is a must. Encrypting data only at rest is not sufficient if it is transmitted or processed insecurely. Let's face it, a firewall will not stop anyone from capturing credit card information being passed over wireless. I wonder if the lawmakers in question truly understood what they are trying to accomplish. An MSNBC story on the subject is here. A very strong (negative) opinion has been posted here. Ensuring or encouraging basic security measures have been installed on all systems is always a good thing IMHO, however does this law miss the boat? The law in question is here.

Cheers,
Adrien

Presently the Norman live Sandbox is unavailable due to a DDoS attack.

See the Norman message for more info.

Thanks Vidar!

To say that we've had a great response to the request for bank sites that do and do not use SSL login pages would be an understatement.

Please keep them coming as we're developing a good list.

Please do understand if because of the volume, I can't acknowledge each one personally and understand that you have my thanks and the thanks of the other handlers as well.

-Chris

This is a bit an old issue I am having, but it seems to be getting worse and not better: Bank that use non-SSL login pages.

Now this is not about sending your credentials in the clear. The bank essentially uses a non-ssl "home page" which includes a login form, but the result of the login form is sent encrypted to an SSL page (e.g. you got to http://www.example.com, and the login form will submit your data to https:/www.example.com). Now why is this so bad, given that your login data is still encrypted? Well, there are two reasons for SSL: The first is to encrypt your data (which happens in this case). The second, as important function of SSL is authentication. A valid SSL connection confirms that you are actually talking to your bank, and that the login form is "real".

With the help of some handlers, we checked out a number of major banks. You can see the result at https://www.securewebbank.com/loginssluse.html . (I will gladdly add more to the list if time allows. If you want to submit any, please let me know the URL of the login page so I can verify).

Another problem, in particular with smaller banks, is the use of "brochure" pages on non-ssl (in many cases even shared servers) that link to an online banking site at a very different domain. Still working on collecting some data about this.

Steve, who is using PeopleSoft, started to get exposed to Oracle's patches. He writes:
Let us know if you have any pointers. I will add hints, URLs and other help to this diary. Among our group of handlers, we have kind of given up on covering Oracle patches due to the large number and missing details in advisories (plus, its not all that easy to get the advisories in the first place).

Kilynn writes that you can signup for notifications at http:/www.oracle.com/technology/deploy/security/alerts.htm . This will also provide access to the "Risk Matrix" which should also help in applying the patches. However, to know more you need to signup for a "MetaLink" account, which appears to be reserved for Oracle customers. (Actually the original poster, Steve, mentioned the risk matrix, but it wasn't too much help for him without details to adjust it for his environment. It wasn't clear to him how to get access to MetaLink as a former PeopleSoft customer).

If you run phpBB, you are probably familiar with bots attempting to attack your sites. Typically, you will find entries in your web log like the following:

viewtopic.php? [...] &highlight=%2527%252esystem(chr(99)%252echr [...]

I omited the long string of URL encoded hex characters. If you run phpBB, grep your Apache access log for 'viewtopic.php', 'highlight' and 'system':

grep viewtopic < access_log | grep highlight | grep system

Now the part you are interested in is what is attempted to be executed as part of the "system" call. In order to quickly decode it, use php's "urldecode" function. Just open a shell, and enter:

$ php -e
print urldecode(" ... [paste gibberish here ] ... ");
?>

Make sure you do not copy any quotes. This will likely reveal an ftp command and with that the location of the actual bot code. Let us know what you find. I posted a quick analysis of a typical phpBB bot here  Important: a few users reported Antivirus alerts after clicking this URL. Since it quotes parts from the bot, it likely triggers some signatures. However, the page wil not execute any malware (trust me ;-) )

These bots typically work all very much alike:

1. search google for vulnerable systems
2. send the exploit
3. the exploit will trigger the download and execution of a perl script
4. the perl script will join an IRC channel and wait for commands.

Typically, the bot is able to launch DDoS attacks, execute local system commands and infect other phpBB systems. In the particular sample analyzed above, the bot makes an attempt to fix the actual vulnerability. If this is successful or not would depend on the bots ability to write to these files (after all, the bot will run as the apache user).
Couple simple counter measures to keep in mind:

• First of all don't forget to patch your systems. Its all too easy to forget random web applications like phpBB.
• make /tmp a non-executable partition. (and link /usr/tmp and /var/tmp to it). Its not perfect, but most of the web based exploits need a place to write their files to, and /tmp is the most common location available.
• block outbound ftp/web traffic from your web server. Many web servers do not need outbound traffic on port 80/21.
• run php in "safe mode"
• for extra credit: chroot apache (not all that easy, but very effective once it is done).
• use mod_security (thanks to Ramon for reminding me about mod_security. its GGGrreat!)
  

And don't forget: These bots will run on any platform which has php and perl installed. You may see them on Linux, OS X, Solaris ... maybe even Windows if the bot gets the paths right.

Oracle has released the April 2006 quarterly patch update. If you have any Oracle software running in your environment, it's probably time for checking to see if you need to patch. Of interest is the updated version of password checking utility (Oracle Default Password Scanner) that was originally released in January, if you have never tested your Oracle databases for default passwords, it's probably a good time to consider a scanning exercise. Default account/password is still by far the most common Oracle vulnerabilities.

http://www.oracle.com/technology/deploy/security/pdf/cpuapr2006.html

-----------------
Jason Lam      jason /at/ networksec.org

We recently received a few requests for help through the contact form without any email address. We are a bunch of friendly folks who always try to help but we simply don't have psychic ability to guess your email address. If you are submitted a request for help, please include your email address so we can contact you. 

For those of us in the U.S, we're coming into the final stretch for filing our Federal tax returns, and the procrastinator that I am has just finished filing.  If you think that doing your taxes isn't stressful enough, you should also be wary of IRS phish.  I am interested in whether the next twenty four hours are going to be an especially mad dash for phishers trying to take advantage of stressed out tax filers and duping them into giving up the keys to their kingdoms.  If you do receive suspicious or obvious IRS phish, I'm interested in the details, but certainly report it directly via email (include full headers) to phishing@irs.gov.

Any and all phish can be reported to the Anti-Phishing Working Group (APWG) following their directions at: http://www.antiphishing.org/report_phishing.html

Handler on Duty (heh*2)
William Salusky

A handler shift on Easter Sunday apparently has (at least :-) two drawbacks. One, inbound reports are considerably thinner than usual. Two, abuse contacts at large ISPs and web hosters seem to be out on an egg hunt or choco bunny meltdown contest or something - provider response to abuse reports and follow-up on reported bot-net controllers has been glacially slow today. Good thing that the major two holiday weekends where IT staff is apparently away from the console are the same public holidays on which the h4x0r kiddies get distracted by sweets or presents...

Over the years lots of software have had hidden easter eggs in them.

An easter egg is an undocumented feature or object.
Definition:
http://en.wikipedia.org/wiki/Easter_egg_(virtual)

Article on finding Easter Eggs in software.
http://www.pcworld.com/howto/article/0,aid,109378,00.asp

Potential issues with any hidden code or resources include:
lack of functional testing
waste of space
wasted software design and coding effort,
too much freedom for the code authors,
inadequate control of quality,
Easter eggs have included backdoors.
implication that no systematic code review was preformed,
Binary patching issues.


Many software manufacturers have had Easter eggs discovered in their production products. Microsoft has had some pretty interesting Easter eggs in the past. My personal favorite was the flight simulator hidden in excel 97.
From: http://www.eggheaven2000.com/detailed/17.html
"How it Works:
1: Open a new Worksheet and Press F5.
2: Type "X97:L97" and press Enter.
3: Press the Tab key, Hold down Ctrl & Shift and left click the Chart Wizard toolbar icon.
4: Use the mouse to move around - Left button reverse thrust, Right button forward thrust.
5: Look around carefully to find the Shrine with the programmers messages and the Blue Lagoon ! "

Microsoft came out with a stronger policy on eastereggs sometime around 2k stating "No hidden features" or "you're fired". http://www.themicrosoftblog.com/16-easter-eggs-in-microsoft-products-youre-fired/

A really good discusion about the microsoft anti-easter egg policy can be found here.
http://blogs.msdn.com/larryosterman/archive/2005/10/21/483608.aspx

A driving game was in first release of Excel 2000 but pulled in SP1 and 2.
Based on the types of Easter eggs being reported in recent Microsoft products, I believe Microsoft still allows the software engineers to put in credits but that portion can no longer include active code such as games. I hope that the credit code is now part of the standard code review process.

Several handlers contributed to this including Swa and Daniel, Thanks!

As already mentioned in Friday's diary, exploits for the Horde App Framework vulnerability are making the rounds. The exploit downloads and installs two variants of Perl/Shellbot which connect back to IRC servers in Germany and the U.S. over tcp/4444. A Nessus Plugin is available to check for the Horde vulnerability.

Microsoft published a knowledge base article about issues with MS06-015. The two main culprits appear to be HP's "Share-to-Web" software and Kerio Personal Firewall.

In order to implement the MS06-015 fix, Microsoft created a special binary (VERCLSID.EXE) which will validate extensions before the windows shell or explorer is able to instantiate them. If VERCLSID.EXE fails to run, many functions are disructed (e.g. open files in applications using the 'File'->'Open' menu).

More stories about patch MS06-013 can be found in a recent Inforworld article. This patch was expected to cause issues due to the changes in ActiveX functionality. Again, see the respective Microsoft statement. Let us know if you experience any issues. So far, everything appears to center around 'Siebel 7'. Given the lack of outcries so far, I don't expect a lot of problems with other applications.

(Thanks to Susan and Juha-Matti for their contributions!)

ISC received an email this morning from a reader that had come across a very interesting article about China and their control of their Internet world.  Summary version of the article is that it is illegal to run an unregistered mail server in China.  According to the interpretation, a new mail server must be registered, by IP address, 20 days before operating the mail server.  One authority quoted in the article, James Seng, says that based on the careful wording of the law, this is not a 'bureaucrat-gone-wild' situation, but a carefully worded document to address exactly what they want.  Additionally, the new regulations restrict discussing certain topics in email, one of them being information security.  This article really highlights how China rules their world, in contrast to ours, and the rest of the Internet world.

As a follow-on to yesterday's discussion about the RIRs and how to use the whois service, Alex sent us some thoughts on a favorite site of his, dnsstuff.  Thanks, Alex!

A reader who wishes to remain anonymous sent us a nice write-up of findings uncovered while investigating an intrusion.  Below is the entire note, minus identifying details. 

And while we're on the subject of web browser updates, version 8.54 of Opera has been released to address a buffer overflow issue in handling cascading style sheets.  Time to upgrade Opera, too.

-----------------------------
Jim Clausing, jclausing //at// isc.sans.org

The Horde Team released version 3.1.1 and 3.0.10 of the Horde Application Framework on 28 March which provided some critical security fixes.  On Thursday, 6 April, we got some e-mail to the handlers list about rumors of exploit attempts and an exploit was publically made available on Sunday, 9 April.  We have now received some logs that show that there are active attempts in the wild to exploit the help code viewer remote code execution vulnerability.  If you are running Horde, you need to upgrade to the latest version as soon as possible.

---------------------------------
Jim Clausing, jclausing //at// isc.sans.org

Just a quick note to mention Firefox has released version 1.5.0.2 (and 1.0.8, for those who were not able to upgrade to 1.5) of it's browser. This update fixes some undisclosed security issues.

Intel based Mac users can choose to install a universal binary instead of running it in roseta. Choose carefully as it has consequences for the way you install it and for the add-ons you might be able to use.

Some of our readers reported trouble finding the downloads in this early stage, the ftp archive has the best chance of success if the automatic updates fail for you.

• Release notes
• Security vulnerabilities that are fixed (still to be published at the time of writing)
• Downloadable files from the mozilla web server
  

--
Swa Frantzen - Section 66

At the ISC we often get requests that end up in us using whois information in one way or another. This diary is about showing some 'tricks' we use to get to the details we need for such events.

PLEASE NOTE:

• These IP addresses are chosen for the educational value, no other implied things good or bad are to be assumed of them.
• Email addresses have been molested to reduce the impact of the bots searching for spam victims.
  

ARIN

ARIN deals with North American IP addresses.

$ whois -h whois.arin.net 129.128.5.191


So this IP address (taken from www.openbsd.org) tells me it's hosted at the University of Alberta in Canada, I do get a technical contact as well.


$ whois -h whois.arin.net 65.173.218.103

Sprint SPRINTLINK-2-BLKS (NET-65-160-0-0-1)
                                  65.160.0.0 - 65.174.255.255
ESCAL INSTITUTE OF ADVANCED FON-1101912576101565 (NET-65-173-218-0-1)
                                  65.173.218.0 - 65.173.218.255

# ARIN WHOIS database, last updated 2006-04-11 19:10
# Enter ? for additional hints on searching ARIN's WHOIS database.

Where did all the detail go ?
Well this address is part of two blocks ARIN is keeping information on and you need to choose which of them you want to see details of. The part between the braces is the block you can select:

$ whois -h whois.arin.net  NET-65-160-0-0-1

OrgName:    Sprint
OrgID:      SPRN
Address:    12502 Sunrise Valley Drive
City:       Reston
StateProv:  VA
PostalCode: 20196
Country:    US

NetRange:   65.160.0.0 - 65.174.255.255
CIDR:       65.160.0.0/13, 65.168.0.0/14, 65.172.0.0/15, 65.174.0.0/16
NetName:    SPRINTLINK-2-BLKS
NetHandle:  NET-65-160-0-0-1
Parent:     NET-65-0-0-0-0
NetType:    Direct Allocation
NameServer: NS1-AUTH.SPRINTLINK.NET
NameServer: NS2-AUTH.SPRINTLINK.NET
NameServer: NS3-AUTH.SPRINTLINK.NET
Comment:    ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE
RegDate:    2000-09-19
Updated:    2004-02-06

RTechHandle: SPRINT-NOC-ARIN
RTechName:   Sprintlink (Sprint)
RTechPhone:  +1-800-232-6895
RTechEmail:  NOC/at/sprint.net

OrgTechHandle: ARINS-ARIN
OrgTechName:   arin-sprint-iprequest
OrgTechPhone:  +1-800-232-3458
OrgTechEmail:  ip-req/at/sprint.net

# ARIN WHOIS database, last updated 2006-04-11 19:10
# Enter ? for additional hints on searching ARIN's WHOIS database.

Well, this kind of information is of the bigger block that generally points to an ISP. It often contains abuse addresses the ISP prefers, but sprintlink didn't include that information here. They did however include an email address for the NOC.

Let's look at the smaller block:

$ whois -h whois.arin.net NET-65-173-218-0-1


It belongs to some institute which some of you might recognize ;-)

CYMRU

Is that all whois has to offer ?

No, by far not. Cymru keeps some more data relating to the routing fabric used on the Internet. As far as routing goes, the IP addresses on the Internet are devided in Autonomous Systems (AS). Each of those has a number, called a ASN. Those AS-es map back to ISPs. The ASNs are used by the ISPs in building links exchanging traffic (called peerings or upstreams). [This is a simplification, I know, but good enough for the purposes of this article].
You can find the AS an IP belongs to:

$ whois -h whois.cymru.com 129.128.5.191

AS      | IP               | AS Name
3359    | 129.128.5.191    | U-ALBERTA - University of Albe

$ whois -h whois.cymru.com  65.173.218.103

AS      | IP               | AS Name
1239    | 65.173.218.103   | SPRINTLINK - Sprint

Now the neat trick is that cymru has a whois server that is aware of the links between the ISPs as well:

$ whois -h v4-peer.whois.cymru.com 129.128.5.191

PEER_AS | IP               | AS Name
6509    | 129.128.5.191    | CANARIE-NTN - Canarie Inc

$ whois -h v4-peer.whois.cymru.com 65.173.218.103

PEER_AS | IP               | AS Name
209     | 65.173.218.103   | ASN-QWEST - Qwest
286     | 65.173.218.103   | KPN KPN Internet Backbone AS
701     | 65.173.218.103   | ALTERNET-AS - UUNET Technologi
1299    | 65.173.218.103   | TELIANET TeliaNet Global Netwo
1668    | 65.173.218.103   | AOL-ATDN - AOL Transit Data Ne
2516    | 65.173.218.103   | JPNIC-ASBLOCK-AP JPNIC
2914    | 65.173.218.103   | NTTA-2914 - NTT America, Inc.
3130    | 65.173.218.103   | RGNET-3130 RGnet/PSGnet
3257    | 65.173.218.103   | TISCALI-BACKBONE Tiscali Intl
3292    | 65.173.218.103   | TDC TDC Data Networks
3356    | 65.173.218.103   | LEVEL3 Level 3 Communications
3549    | 65.173.218.103   | GBLX Global Crossing Ltd.
3561    | 65.173.218.103   | SAVVIS - Savvis
4134    | 65.173.218.103   | CHINANET-BACKBONE No.31,Jin-ro
5511    | 65.173.218.103   | OPENTRANSIT France Telecom
6762    | 65.173.218.103   | SEABONE-NET Telecom Italia Spa
7018    | 65.173.218.103   | ATT-INTERNET4 - AT_T WorldNet
15412   | 65.173.218.103   | FLAG-AS Flag Telecom Global In

This gives you a list of ISPs that have a relationship with the ISP that is hosting the IP you are looking for. Should you be trying to push an unwilling ISP to act, contacting these peers in "cc" is a great means of applying presure.

RIPE

Now what happens if you try to lookup an address in Europe ?

$ whois -h whois.arin.net 194.7.3.21


That's not going to help you, RIPE is an organization much like ARIN, but instead of North America, they cover Europe and the Middle East.

Actually read more closely: ARIN does point you to whois.ripe.net, so let's contact that server.

$ whois -h whois.ripe.net 194.7.3.21

Cool, we got the ISP and an abuse contact.

The ASNs are filled out in this format as well. However, should you want to use the information, I'd trust the cymru results just that bit more.

APNIC

Moving on to Asia - Pacific, things change again. Should we try to pull the information off of ARIN, it will point us to whois.apnic.net (not show for brevity).

$ whois -h whois.apnic.net 202.30.50.50

OK, for tracking down an ISP this answer is a hard one. But read it carefully: it tells you to look for more detailed information on whois.nic.or.kr ...

$ whois -h whois.nic.or.kr 202.30.50.50

Cool, we got a NOC contact!

LACNIC

Lacnic is responsible for Latin America, let's try it:

$ whois -h whois.lacnic.net 200.160.7.7


Don't worry too much about those long lists of nameservers. They are almost always there with lacnic.

AfriNIC

I've never had to deal with the fifth RIR: AfriNIC in real life, but here is an example:

$ whois -h whois.afrinic.net 196.216.2.1

Domain names

Whois also can be used as an interface to see who owns what domain name, but that's for another time.

Other sources

There are many more sources of whois information. The trick aside from the starting points above is to read the comments that are given back. Sometimes some information isn't available through the whois information due to risks of abuse. Often they'll point you over to some website with some detection of automated processes and perhaps even only giving out the information as a gif file instead of text.

--
Swa Frantzen - Section 66

Microsoft also updated MS06-005 but it was not included in the bulletin today.

According to Microsoft:  Updates are available for Microsoft Windows Media Player 10 when installed on Windows XP Service Pack 1 or Windows XP Service Pack 2, listed in the "Affected Components" section. For more information, see on "What are the known issues that customers may experience when they install this security update?" Additional clarity under "How could an attacker exploit the vulnerability?" in the "FAQ for Windows Media Player Vulnerability" section.


For more information see the complete bulletin.
Vulnerability in Windows Media Player Could Allow Remote Code Execution (911565)

We received a link to an interesting article today from one of our readers. (Wishes not to be identified.) If the information in this article is true, this could be an interesting time for the novice home users. The article says that some sites that rely on popular ActiveX controls such as QuickTime, RealPlayer and Flash and Acrobat are likely to give users fits. It will be interesting to see what happens in the next few days. Again Stay Tuned.

IE Changes Due: What You Can Expect

Adobe Active Content Development Center

The Handlers have formed, we are online in our secret chambers and poised to jump on the Microsoft updates.  We are doling out the responsibility for the write ups and just waiting for the release of information.  Stay tuned for updates.

In the meantime take a look at what Microsoft has in store for you..

http://www.microsoft.com/athome/security/update/bulletins/200604.mspx

It seems that the information is beginning to trickle down.  It appears that we have:

3 Critical

Cumulative Security Update for Internet Explorer (912812)

Vulnerability in the Microsoft Data Access Components (MDAC) Function Could Allow Code Execution (911562)

Vulnerability in Windows Explorer Could Allow Remote Code Execution (908531)

1 Important

Cumulative Security Update for Outlook Express (911567)

1 Moderate

Vulnerability in Microsoft Front Page Server Extensions Could Allow Cross Site Scripting (917627)

Update for Outlook 2003 Junk Email Filter (KB914454)

Microsoft released an update to the Junk E-mail Filter in Microsoft
Office Outlook 2003.  This update provides a more current definition
of which e-mail messages should be considered junk e-mail.

Windows Malicious Software Removal Tool - April 2006 (KB890830)

Microsoft released the monthly update to the Malicious Software
Removal Tool (MSRT).  The newest version supports 3 new specific and
prevalent malicious software which may be on infected computers.  For
more information on the new additions, please see
http://www.microsoft.com/security/malwareremove/default.mspx  for
details.  As a reminder this tool is not supposed to be a replacement
for your corporate or individual owned antivirus and spyware protection.

As an addition to Williams terrific diary from yesterday, I would like to add a comment.

In the US the FBI and other law enforcement agencies have designated the National Center for Missing and Exploited Children as there reporting center for reporting Child pornography and other criminal issues dealing with children.  For more information see there web site.

http://www.ncmec.org/

According to Investor's Business Daily online fraud is still on the rise.  And unbelievably the Nigerian Scams still top the list for losses. 

In case you don't know what the Nigerian Scam is:
" In this scam, victims are guaranteed millions if they help the fraudsters by giving them an upfront loan in order to transfer a ton of money out of Nigeria. This scam dates back to at least 1996."

http://www.investors.com/editorial/IBDArticles.asp?artsec=17&artnum=1&issue=20060406

Folks - You can NOT get rich this way. As a matter of fact you can get real poor this way.    When will people realize that if it seems too good to be true it probably is.

Yesterday afternoon I got a phone call from a local non profit organization. A plea for help really.

A year ago they were going through a change in leadership, board, etc. at the same time as their web site URL was set to expire. They were unaware that they were on the verge of disaster until they received a phone call from a local citizen who had made a gruesome discovery, the web site now contained Porn.  They have learned a very hard lesson.

It has been a year and they are still getting calls from people saying  "do you realize your website contains porn?".  They have to explain to the caller that their web site has changed to the new url and that they are trying to get all of the search links straightened out. (When I google for this organization I came up with close to 1000 entries. On the first google page there were 3 occurrences of the old web address being linked the organization.)  

This organization is popular with both adults and children.  So now we have the potential of children happening on to the site.  

To add fuel to the flame this site attempts to hijack your web browser as well. Once hijacked you get the pleasure of pornography every time you open your browser. For most people this will mean a bill to pay someone to "fix" their computer.

When discussing this with local FBI they indicated that what had happened was not illegal, it happens all the time.

I have to ask myself "how can this be legal"?  How can someone take a website that was owned by someone else and grab it for their dirty deeds?  How can they create a web site that causes "damage" to someone else's computer?  How can they cause potential damage to children by displaying this type of material?  Why is none of
this illegal? (It isn't illegal, perhaps unethical and immoral,  but NOT ILLEGAL).

It has been a year and this small non profit organization has spent time, money and resources trying to undo what has been done. They will probably never get all of the occurrences of these removed from the search engines.  And if someone looking for their web site types in  .com instead of  .org they will be greeted with porn.

I urge all of you to check your web registration and make sure that you know when it is due to be renewed and renew early.  Don't take any chances. These folks are laying in wait, waiting for your web site to expire so that they can snap it up and display their dirty merchandise.

I am interested in hearing from others that have had this happen, if and how they resolved it.

Most banks are moving over to various two factor authentication systems these days. Does two factor authentication actually mitigate the security problems such as phishing that plagued the traditional username and password based authentication? Two factor authentication is stronger than the traditional authentication system but it definitely has its own problem as well. The following article provides some insight into the potential problems of two factor authentication.

http://www.networksec.org/index.php?n=Articles.AuthenticationThePitfallOfTwoFactorAuthentication

        It's been a quiet day, with a few reports of phish and pop-up
spam.  It looks like we haven't covered spam reporting in a while.

        Because I work so much with spam already as part of the
sa-blocklist and SURBL projects, I take an additional step and report
spam to the organizations and agencies that have interest in certain
spam categories.  I tend to prefer email accounts to which I can
<a href="http://www.stearns.org/doc/spamassassin-setup.current.html#redirect">bounce</a>
spam emails as this is easier to script than trying to send the emails
through web forms.

        First, the FTC will take any spam you get; send it to
uce_at_ftc.gov .  Also, spamarchive.org is interested in any spam you
have, but please send it as an RFC822 attachment (see your email client
docmuentation on "How to send as an attachment") to
submitautomated_at_spamarchive.org .

        Here are the reporting addresses I use, by category:

- Theft of cable services: ocst_at_ncta.com

- Child pornography: children_at_interpol.int, gmail_at_cybertip.ca .
Other than these, do <i>not</i> redistribute the spams, visit any
advertised sites, or keep the emails.  You shouldn't send these to
spamarchive.org as these are republished on an ftp server.

- Nigerian/419 scams
(<a href="http://home.rica.net/alphae/419coal/">http://home.rica.net/alphae/419coal/</a>):
419.fcd_at_usss.treas.gov

- OEM software: netpiracy_at_siia.net, piracy_at_microsoft.com

- Phish scams: reportphishing_at_antiphishing.org,
phish_at_ists.dartmouth.edu, spam_at_mailpolice.com .  Also,
postmaster_at_corp.mailsecurity.net.au and report_at_reportphish.org are
interested, but please send the phish mail as an RFC822 attachment.

- Pills: webcomplaints_at_ora.fda.gov, drugs_at_interpol.int

- Pyramid scams: fraud_at_uspis.gov

- Rolex/replicas: steve.gobin_at_rolex.com, expert_at_lpconline.com

- Stock/pump and dump: enforcement_at_sec.gov

- Tobacco: alctob_at_ttb.treas.gov

- Viruses: avsubmit_at_symantec.com, newvirus_at_kaspersky.com,
samples_at_F-Secure.com, virus_at_cai.com, virus_at_commandcom.com,
virus_at_pandasoftware.com, virus_doctor_at_trendmicro.com,
virus_research_at_nai.com

        Some of the above came from
<a href="http://spamlinks.net">Spamlinks</a>
<a href="http://spamlinks.net/track-report-addresses.htm">Reporting</a>
page - many thanks for an excellent resource.  The email addresses I
covered above tend to be focused on US agencies; definitely visit
spamlinks if you live outside of the US.

        -- Bill Stearns (
<a href="http://www.stearns.org">http://www.stearns.org</a>,
<a href="mailto:wstearns@pobox.com">wstearns@pobox.com</a>)

Symantec has issued information on MSIL.Letum.A@mm, "a worm written in Microsoft .NET's Microsoft Intermediate Language (MSIL) that can affect both Windows PC and Windows Mobile powered devices that have the .NET framework installed.". Trend's analysis for WORM_LETUM.A is here.

Alcan.B is circa June, 2005. MS's anti-malware technology team has blogged that "In February's release of the tool (MS's Windows Malicious Software Removal Tool), we added the ability to detect and remove a worm called Win32/Alcan.". So seven months and a few days after information about Alcan.B was first published, MS's Anti-Malware Engineering Team is "genuinely surprised" that 250,000 of the 250 million computers systems that ran the February Windows Malicious Software Removal Tool were infected with Alcan.B.

The Anti-Malware Engineering Team blog goes on to note that the February Windows Malicious Software Removal Tool removed the "Win32/Mywife.E worm (aka CME-24)" from 40 thousand computers, starting just a scant 11 days after the "worm" detonated on February 3rd, 2006, less than a month after it's discovery date (near January 17, 2006). Win32/Mywife.E is malware that the Anti-Malware Engineering Team had recently said was a worm that "turned out to be more hype than reality", and that "the few calls they did receive tended to be inquiries based on word-of-mouth vs. infected users" (Monday, February 06, 2006 12:38 AM).". Looking back on the week (graphic next - as Nyxem.E), "Win32/Mywife.E worm (aka CME-24)" gets around, and looking back, at other statistics, over the time period since it's release, it competes right up there with other prolific persistent malware like MyTob and netsky, and will continue to do so in the future.

phpBB, a popular forum has released version 2.0.20 on this Friday.

There are a number of security issues fixed and due to the past interest of the bad guys, upgrading is highly recommended.

Upgrading consists of a number of phases:

• copy your content to safeguard it;
• carefully patch your files:
• Take care with added or changed templates (only subSilver gets patched automatically);
  
• Take care with any mods you might have on your board.
  
• copy the contrib and install directories;
• run the upgrade php script to upgrade the database through the browser;
  
• remove the contrib and install files;
• test.

I'd suggest to look at turning on the CAPTCHA test, I had problems with it before, but it now seems to be finally working properly.

Another thing you might want to do is to remove the memberlist.php references in the templates and chmod 0 that file. All those subscribers that don't post anything but have links in their profile to adult content get a bit less encouragement that way. It might trigger them to post spam so you can ban them.

--
Swa Frantzen - Section 66

Viruslist is reporting on a cross platform Proof of Concept (PoC) virus that works on both Linux and Windows machines. It is claimed to be capable of infecting both the linux ELF binaries and .exe's from windows.

The impact of the PoC at this point is very low in itself, but it is a sign the cross platform aspects are becoming important. As the developers of viruses continue to research this, we will see (more) cross platform malware come about in the future.

Even today websites sending exploits to their visitors tend to detect what browser/platform the visitor is using and send a matching exploit to install some malware and earn their quarter for each confirmed installation.

Planning ahead and also protecting the Linux, UNIX and Mac OS X, machines with anti-virus measures is a good thing to start on now if you haven't done so already.


Getting infrastructure that is fed signatures in an automated manner in place allows you to shorten the time needed to respond, even if the specific platform isn't targeted today. Since anti-virus measures are mostly reactive in nature, anything that makes your reactions faster is good.

--
Swa Frantzen - Section 66

No major events, so here is a brief listing of the items that I was tracking throughout the day:

• MS sent out the advanced warning for patches next Tuesday: http://www.microsoft.com/technet/security/bulletin/advance.mspx
• A new vulnerability was announced in Internet Explorer.  The vulnerability is a race condition between loading web content (HTML) and flash files.  It allows people hosting malicious websites (phishing) to overwrite the URL address bar.  This would be useful in phishing attacks.  Details here: http://secunia.com/advisories/19521/
• A reader reported a Chase bank phishing e-mail with only a 888 phone number to dial.  My first guess was that this would be a number that charged a very high fee upon connect, so I didn't dial it.  But he reported that when you dial the number, a system prompts you for a 16-digit card number and seems to have a validation process.  Perhaps this is the next wave in phishing attacks?  He reported it to Chase bank and antiphishing.org.
  
• For a brief time this morning (in the US), the SSL certificate for Hotmail was broken.  It gave the SSL certificate for www.gendcom.info, which seems to be a legitimate site that uses SSL.  The Hotmail SSL certificate was quickly fixed.  After researching, I discovered that both organizations use Savvis webhosting.  So I'm thinking this was a technical glitch at Savvis.
• The folks running the bleeding-edge snort project had to move their web servers to a different provider temporarily due to a DDoS attack.  So you may find intermittent connectivity to them.

Tim Callan (Verisign) sent us this note:

"VeriSign reports that many public-facing Web sites continue to implement an older and less secure version of VeriSign's popular security mark. Because the old VeriSign site seals were created and distributed prior to the rise of phishing, they did not contain the full set of anti-spoofing measures available in the newest version of the VeriSign Secured Seal. For the protection of online consumers, VeriSign is in the process of phasing out its old-architecture seals and moving forward with support only for the newest version of the VeriSign Secured Seal. Old-version seals are in a round, "gold or silver medallion" shape and call their verification page from https://digitalid.verisign.com. Latest-version seals contain the black VeriSign check mark in a red circle and the words VeriSign Secured and call their verification page from https://seal.verisign.com. All Web sites employing one or more VeriSign SSL Certificates in their validity period are entitled to display the VeriSign Secured Seal to improve site visitor confidence and increase visitor propensity to complete transactions. These customers can download the latest version of the VeriSign Secured Seal free of charge at  www.verisign.com/seal."

Looks like our long-time "friends" from the Coolwebsearch/Trafficadvance malware department have moved shop to a new hoster. If you've followed our earlier suggestions and zapped their old netblock (81.9.5.x), well, then you might want to consider banning their new sites as well. They all seem reside under  85.249.23.x now, again in St.Petersburg, Russia. If you prefer to block their domains, here's a list. All of the indicated domain names end in .biz.

traffsale1 traffweb toolbarweb toolbarsale iframecash traffcool toolbarcool traffbucks toolbarbucks traffdollars toolbardollars traffbest toolbarbest traffnew toolbarnew traffmoney toolbarmoney vip01

Be advised that unwary surfing to these sites might make your DVD drive spit out peperoni slices, cause your monitor to start flickering, and definitely will result in other side effects detrimental to the integrity of your beloved computing device. You have been warned.

We made a couple of changes to the site recently:

• The RSS feed is now available in two versions. One with headlines only (as before) and a second version with full content.
• In addition, we now offer a "Security News Feed" which aggregates feeds from various security related sites.
• removed a ton of little html issues that should bring the site closer to HTML 4.01 strict compliance. Not 100% there yet, but close.

In other news: We rebooted one server this morning and as a result, a ton of old queued up messages got released. You may see some old update notifications in your inbox.

You can always subscribe to our "new diary notification" service to have a brief link sent to your pager/phone if there is a diary or infocon update.

Links:
News Feeds
New Diary Notification E-Mails.

Subscribers of the ISC alert service were today presented with a handful of old messages from back in January. While it is always nice to read about problems long past and resolved, we'll try to convince our server not to ruminate stale news all too frequently, and apologize for the inconvenience caused.

Being an IT Professional, I'm sure you frequently get to "help out" your less IT-literate relatives and neighbours with their computer problems, real and imaginary.  Recently, I had the opportunity to fix a problem of the "real" kind - a very dead hard drive that wasn't even willing to spin anymore. Good thing is, only months earlier I had converted that same PC to backing up to an external USB drive - and since everything was so easy and quick now, Grampa had been doing his backups just as religiously as taking his fiber supplement at breakfast.

Bottom line: External USB drives make a pretty neat and cost effective backup media for home users. Combined with a customized "single click" scripted backup icon on the desktop, and the instruction to always turn the USB thingy off again after backing up (so that the worm/virus doesn't get the backup as well), Grampa should be reasonably safe. Checking back, I found that he had made two backups to the CD writer in one year, and - surprisingly - weekly backups to the USB drive.

In an increasingly technological world it is easy to forget that social engineering attacks will always be bigger and more damaging than the latest 0-days.  The best hacks are the ones that have significant "people" components.  That's why it is surprising that both Microsoft and SecurityFocus seem taken aback by a relatively unknown piece of spyware being so successfully deployed using social engineering.  It is well-known that most intrusions are insider (aka people) attacks. In the days before Outlook flaws, e-mail viruses had to trick users into running attachments.  There will always be an occasional vulnerability that will have the security people scrambling, but there will always be users who run things they shouldn't be running.

The idea that the unsophisticated consumer will be able to protect their information is not one that is valid in the light of the amount of accounts that are compromised.  Phishing is a great example.  There would be little to no phishing if people couldn't be tricked into ponying up their information.

There are two ways to solve this problem and both are required.  The first is security education which will help but won't solve the problem.  Consumers have more on their minds than to dedicate their entire time to learning system hardening.  They need to take some basic steps like patching, anti-virus, and anti-spyware but that won't be enough. The other component is finding ways to do business that take into account that consumer PCs are not trustworthy for data that shouldn't be for public consumption.  Ways must be devised to treat the PC (much like the Internet in general is treated) as a hostile medium for information and protect the data accordingly.

--
John Bambenek // bambenek -at - gmail -dot- com
University of Illinois

We've gotten several reports of QWest outages, particularly in the Pacific Northwest region of the United States.  QWest hasn't reported anything but people have sent in failing traceroutes and I can no longer get to them from where I am at.  It appears to be unreleated to the NetSol problems, but sites in that region of the US will be experiencing intermittent problems.  More as I get it.

Update 1:34 CDT:

It appears AOL Instant Messenger is having intermittent problems, possibly connected to this, though I have no firm insights into it.

This morning from about 8am-10am eastern Network Solutions services were unavailable again.  At the time of this writing they still haven't come "fully" up.  They explained the interruption as being caused by a "global outage" from their colocation provider.  They did not explain the nature of that outage.  In theory, things should start to work again over time. (Note: This is a different outage than yesterday allegedly).

Update: (12:05pm CDT) A Lesson in Business Continuity Planning

While I think the explanation is somewhat lacking on what happened at NetSol, there is one thing that jumps out at me.  Why is the failure of one vendor enough to cause all of NetSol to come crashing down?  You could argue that you rely on your vendors to have redundancy but sometimes the vendor itself can be a single point of failure.  In this case, it looks like the vendor's entire enterprise crumbled and took NetSol with it.  Even the most technologically robust firms can be brought to a halt by a labor strike (for instance).  The moral of the story is that if the stakes are high enough having redundant vendors can be a smart play.

Update (4:15pm CDT) Don't Believe Everything you Read on the Internet

Contrary to reports circulating on the Internet, this outage was not the result of a DoS attack.  I have spoken via email with one of the NetSol engineers and while I can't say what it is, I can say it wasn't an attack.

We've received and confirmed reports that NetworkSolutions is down (@ 13:15 UTC).  While networksolutions.com resolves, their website appears to be down.

According to several emails I've received, they should probably be using Ce1abrex and purchasing ALL of their p4armacutica1s from Canada.

Note: If you're going to write in to tell us you can't resolve a domain, please tell us WHAT domain.

Note 2: We'll post more information when we find out what's going on...

Update (14:25 UTC): They're baaaaaaaaaaaaaaaack.... We still have no information on what went south.  If we find out, we'll let you know.

"A little nonsense now and then, is cherished by the wisest men."
                                                                            -[W|B]illy Wonka

The Oompah Loompahs are, once again, hard at work, cooking up a fresh new batch of Everlasting Hack-Stoppers (i.e. IE Patches) in Billy Wonka's Redmond Chocolate factory.

Good for them.

These fresh, new Everlasting Hack-Stoppers are aimed at fixing two unpatched vulnerabilities in Wonka's World-wide Web Browser (i.e. IE).  Just like back in January, exploits are a'circulatin' while we wait for the Oompah Loompahs to complete their tasks.

"So much time, and so little to do! Strike that, reverse it."
                                                                            -[W|B]illy Wonka

I, personally, have a whole lot of respect for the Oompah Loompas and for the tasks that Billy Wonka has placed before them-- but let's get serious.  Microsoft has been slinging Windows code for around a decade and a half now, and we still find ourselves waiting weeks for the other shoe to drop while security patches are tested and translated into every modern language and Latin (Quidquid latine dictum, altum videtur.)

The problem is: every admin worth his salt will be re-testing that same patch once it's released.  And that, my dear friends, means that even when the patch is released, the corporate world will still be waiting.

"We are the music makers, and we are the dreamers of dreams"
                                                                             -[W|B]illy Wonka

Why should there be even more delay before the actual application of patches with public exploits-- by several additional days beyond their release date?  Why should the Oompah Loompahs get all of the patch-testing fun?

I, a dreamer of dreams, have a modest proposal for Mr. Wonka.  Release your Everlasting Hack-Stoppers twice.  When there are public exploits in circulation, release un-supported beta patches as early as possible.  Let the end users have a crack at testing them CONCURRENTLY with your Oompah Loompahs.  You can put all kinds of onerous click-through "WE ARE NOT RESPONSIBLE" verbiage on them, and let 'em rip.  You could even create a return pathway for the testing public to send reports back to Redmond.  That would give your testing program a wider range of real-world experience than all the Oompah Loompahs in Redmond could provide. Finally, when the Oompah Loompahs are through testing, release 'em for real.

With two sets of zero-day IE flaws hitting thus far in 2006, don't you think the current state of the patch cycle is worth a little dreaming?

Finally, before I bid you my fond farewell as Handler of the Day, I'll pull out my Nostradamus beanie and leave you with a prediction: Crpk wep xpdw apvk, up uohh fpp v svtck OP fpqgkowa offgp qvgfpi na wep gxqcgjhoxl cz VqworpD qcip igp wc wep Pchvf jvwpxw.

Good night, Mrs. Calabash-- wherever you are.

---

Tom Liston - Intelguardians

It appears that the new WindowsCE based Treo 700w had some "issues" with DST.  According to Palm:

"After Daylight Saving Time begins (2:00 a.m., first Sunday in April), you may notice that some appointments in your smartphone's Calendar appear one hour early. For example, if you had scheduled a dental appointment for 9:00 a.m. Monday, it would appear on your smartphone as 8:00 a.m. Monday; it will also appear incorrectly in Outlook on your desktop PC as 8:00 a.m. Monday.

In addition, full-day appointments may appear one day early."

The point?  Well, first off, because I own a Palm OS based Treo 650, I enjoyed having the chance to take a cheap shot at Palm/MS for the 700w's problems.  But beyond that, this issue harkens back to a diary entry by the always suave and debonaire Mr. Tony Carothers.  While dealing with the whole DST protocol seems, on the surface, to be pretty simple, there are always hidden "gotchas" lurking out there that rear their ugly heads every spring and fall.  Remember-- On tap for next year: The U.S. Congress gives the DST Gotcha Tree a healthy shake... anyone else wondering what'll fall out?

Steve and the gang out in Cupertino have made Mac OS X v10.4.6 and Mac OS X Server v10.4.6 available for your fruity OS-updatin' pleasure. Aside from providing some general system improvements, they also deliver a fix for a security issue whereby MacIntel (Inteltosh?) boxes could have their firmware password bypassed, essentially giving anyone with physical access to the box the ability to drop to "Single User Mode" and run amok. (More details here.)

Update links and checksums (you *do* confirm checksums before patching, now don't you?):

Go here. (http://www.apple.com/support/downloads/)

For Mac OS X v10.4.5 (PowerPC)
The download file is named: "MacOSXUpd10.4.6PPC.dmg"
Its SHA-1 digest is: b65564786f9e15d6bdac2ea3eed1294e5fd8f122

For Mac OS X v10.4 through Mac OS X v10.4.4 (PowerPC)
The download file is named: "MacOSXUpdCombo10.4.6PPC.dmg"
Its SHA-1 digest is: c9fde5a23bcebd08149301b7ad300881a563c398

For Mac OS X v10.4.5 (Intel)
The download file is named: "MacOSXUpd10.4.6Intel.dmg"
Its SHA-1 digest is: a0d26811f55c8a3accac0f0237355431d0ca3938

For Mac OS X v10.4.4 (Intel)
The download file is named: "MacOSXUpdCombo10.4.6Intel.dmg"
Its SHA-1 digest is: 487dfcb211911c97f9862872a70b72eb4486d724

For Mac OS X Server v10.4.5
The download file is named: "MacOSXServerUpdate10.4.6.dmg"
Its SHA-1 digest is: 17b92d74ebe0a499fee5189b6d1074d5d5f72b15

For Mac OS X Server v10.4 through Mac OS X Server v10.4.5
The download file is named: "MacOSXSrvrUpdCombo10.4.6.dmg"
Its SHA-1 digest is: 746fe2b304f8bfb6a5f84ff0e08edd32722a8cb9

Or, you can be a big old wimp and just use the Software Update pane in System Preferences... (thanks Swa, for pointing that out!)

One of our reader's submitted a good question to ponder on this Sunday, and I though I'd share that question with everyone: "what about (people) running less than currently supported (OS) versions? Are they going to be forced to change to manual adjustments?  My response was something like "... I'd disable the auto adjustment, and make a short trip into the office Sunday morning to make the manual adjustments necessary.  One could even use 'Scheulder' to write a simple script to do it for them if they were brave......" 

So, I'd like to ask you; thoughts?

(I'd like to thank Scott H. for the inspiration and insightful questions)

     For those who read this Saturday, April 1st don't forget to compensate for daylight saving time.  However next year daylight savings time, in the United States anyway, will be observed on March 11th, thanx to a bill passed by Congress.  Additionally, it will end one week later, on Nov. 4th, instead of the usual 'last weekend in October'.

     One more note: It's a good idea to change the batteries in your home smoke detectors twice a year, and this is a good day to remember to do that.

Wishing everyone a happy April Fools Day (http://en.wikipedia.org/wiki/April_fools) the ISC.  I'm not a big fan such silliness, but I appreciate the important lessons it tries to teach.

 

Some of the fun that's crossed my screen today:

http://www.worldofwarcraft.com/burningcrusade/townhall/wisps.html

http://www.google.com/romance/

http://www.thinkgeek.com/stuff/41/wec.shtml

http://slashdot.org

 

Although some don't like it when I put up a link to exploit code, here is a special 4/1/2006 exploit for you:

http://www.metasploit.com/archive/framework/msg00919.html

 

Irresponsible disclosure. :-)

 

Today's signifigance makes a good opportunity to educate your friends and neighbors about the everyday April Fools pranks going on in your email boxes.  Teach them the skills to recognize legitimate websites, avoid clicking on links in unsolicited email, recognize spoofed email, and think critically.