• AirPort - CVE-ID: CVE-2006-5710 *
  
• ATS - CVE-ID: CVE-2006-4396
• ATS - CVE-ID: CVE-2006-4398
• ATS - CVE-ID: CVE-2006-4400 *
  
• CFNetwork - CVE-ID: CVE-2006-4401
• ClamAV - CVE-ID: CVE-2006-4182 *
  
• Finder - CVE-ID: CVE-2006-4402 *
  
• ftpd - CVE-ID: CVE-2006-4403
• gnuzip - CVE-ID: CVE-2006-4334, CVE-2006-4335, CVE-2006-4336, CVE-2006-4337, CVE-2006-4338
• Installer - CVE-ID: CVE-2006-4404
• OpenSSL - CVE-ID: CVE-2006-2937, CVE-2006-2940, CVE-2006-3738, CVE-2006-4339, CVE-2006-4343
• perl - CVE-ID: CVE-2005-3962 *
  
• PHP - CVE-ID: CVE-2006-1490, CVE-2006-1990 *
  
• PHP - CVE-ID: CVE-2006-5465 *
  
• PPP - CVE-ID: CVE-2006-4406 *
  
• Samba - CVE-ID: CVE-2006-3403
• Security Framework - CVE-ID: CVE-2006-4407
• Security Framework - CVE-ID: CVE-2006-4408
• Security Framework - CVE-ID: CVE-2006-4409
• Security Framework - CVE-ID: CVE-2006-4410
• VPN - CVE-ID: CVE-2006-4411
• WebKit - CVE-ID: CVE-2006-4412 *
  

It's time to update your Honeynet technologies toolbelt!

Honeynet Project - HoneySnap tool

• The python based honeysnap client is making a fresh debut at v1.0.1 and offers some reasonably nice post-processing and text based reporting on packet capture.  The Honeysnap tool can be used standalone outside of a Honeynet environment or blends nicely with any pre-existing Honeywall deployments.  I 'like' it.

Nepenthes update release from the MWCollect project

• A favorite is the Nepenthes malware collector that grew up with mwcollect, and after combined efforts this year we've been bestowed with the recent point release of v.20.

Honeynet Project - Upcoming Honeywall improvements

• While the Honeywall has not released updates lately, there has been some significant development effort exerted this year within the project.  I'm personally hoping the next generation makes a public release very soon.

Mitre Honeyclient project

• There has not been any fanfare lately but there has been some motion in the Mitre Honeyclient project.  Honeyclient code has been made available for download and a fair amount of documentation is published in the project wiki. 
  
• Of note, but with no insight into why it may have occurred, the Mitre honeyclient project has just recently migrated from away from the mitre.org domain out to new hosting. 
  
• You should really consider deploying this type of technology if you'd like to 'literally' drive your browser crazy.  Go find some some new badness and make sure to report back on your findings.

And then there's your flow data

• The DShield project is always interested in obtaining aggregate netflow data based on unwanted internet traffic received at your home/business internet connection end point.  This helps not only us, but provides you with a reporting interface into internet traffic trends that occassionally identifies new or otherwise targetted attacks. 
  
• There is a wealth of documentation demonstrating how you can participate in the Dshield project, including the client tools available to start reporting this data back... and heck, if you're not doing anything with it, DShield wants it!

We've received reports from .edu (Thanks!) of a massive new outbreak of bots exploiting the Symantec Client Security and Antivirus escalation of privilege vulnerability.  ("new" implying the outbreak, not the vulnerability :)

More details on the vulnerability here.

We have not seen the botnet here at the ISC, but if you are having experience with it, please write in via our "Contact Us" Button, and let us know!

Update #1:

Port traffic on the Symantec Client port (2967) has drastically increased in the past few days.

A reader has reported an instance of possible malware delivered to his machine from the Chinanet network.  A number of AV products have identified the code as possible Malware, i.e. suspicious file or possible Trojan.  Initial tests haven’t shown anything conclusive.

The file was an executable called ok.exe.

Mark H

ISC Handler On Duty

One of the handlers found an interesting article on the net which raises some interesting questions and describes an interesting attack vector for the delivery of malware. 

Essentially it uses frames within word documents.  When using frames in the document you can link the content of the frame to a URL, which will be downloaded and displayed (if relevant) when the document is opened.  So this is similar to the URL links in the SPAM emails we all get.  However the email links require a click, whereas this requires you to open the document.  People nowadays are wary of clicking on links in emails, but will happily open a word document when it seemingly was sent by Aunty Joan, the boss, or someone else they know.

So in a few minutes of thinking we came up with a number of interesting uses of this feature, ranging from tracking documents being opened to malware being downloaded and installed and of course the original use as described in the article.

What to do about it?  Controls on web traffic would be  one defence, for example content scanning or URL blocking.  The payload has to be delivered, so if web traffic is controlled the risk is reduced.  To prevent email delivery, block word documents.  I know a number of sites where this is the norm and it works for them.  But still one of the best defences is an informed userbase, so awareness training.

Other products may have similar issues, so be aware.

The article can be found here.

Mark Hofman
ISC Handler On Duty
shearwater.com.au

Sadie from the UK reported that a number of ebay groups are having issues, defacements, deletions etc. 

Wow first shift as the Handler of the Day. 

It started pretty ominously.  A few days ago I accidentally mentioned the q word and was promptly told that it would come back and bite me.  And bite it did.  This morning I logged on to get ready for the next 24 hrs when the power for my neighbourhood disappears.  My little UPS happily humming along and providing power, but alas my internet connection somewhere between my house and the ISP was not so lucky.

Anyway things are back, I'm ready for the day (sort of) and the cricket is on (Go Aussies).

Availability is one of the three key aspects of information security, it is also the most often neglected aspect. To safeguard against data lost due to harddisk crashes, backup is absolutely necessary. The backup idea is simple, just make a duplicate copy of the data and store it somewhere safe and ensure you can access the backup data when you need it. This simple idea is actually difficult to implement, cost of backup media and equipment, safe transport of media to the "safe" place, scheduling the backup job regularly, etc.... Things are even worst for home and small business users who have limited knowledge and resource. There are quite a few online storage companies marketing their solution as secure online backup solution. One company even offers 25GB of free storage space for anyone to store their files online.

The online backup vendors seem to all claim themselves as very secure and can protect your data properly. A lot of them simply copy your files via an SSL tunnel to their datacenter and store the file as is. Not sure how you like the idea of some other companies storing your important (sensitive) files and have access to them. I personally dislike that idea a lot and I think data should be encrypted before shipping over to the backup location.

There are some solutions that encrypt the data before shipping it over to the datacenter, making it impossible even for the online storage vendors to read your content (if the client hasn't been backdoor that is). While choosing an online backup vendor, be sure to look for encryption capability, encryption before you send them the data, that is.

Make sure you also periodically check to see if you can retrieve the data (unencrypt the data). For the encryption key, either select something that you can remember real well or have a copy of the key available somewhere. For the forgetful readers, you might want to consider copying the encryption key on a USB key drive and put that in your safety deposit box or other safe location (outside of your primary residence/office).

With the technology available today, backup is real easy and cheap. However, you must do some proper planning to ensure your backup data is safe and sound, most importantly, available when you need them.

You might also want to review our previous stories about backup:

http://isc.sans.org/diary.php?storyid=1589

http://isc.sans.org/diary.php?storyid=702

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

1. Generates a step1.exe file that will be tied to that dvdaccess[1000-1300].exe file and the IP address of the downloading host.
2. Takes the pre-compiled step2.exe file that corresponds with the requested dvdaccess[1000-1300].exe file.
3. Packages them together and hands them to the Web server to present to the requester.

Virtual machine detection is a self-defensive property of many malware specimens. It is aimed at making it harder to examine the malicious program, because virtualization software, such as VMware, is a very popular tool among malware analysts. For instance, 3 our of 12 malware specimens recently captured in our honeypot refused to run in VMware.

There are many ways for malicious code to detect that it's running in VMware: looking at the presence of VMware-specific processes and hardware characteristics are some of the simpler ones. More reliable techniques rely on assembly-level code that behaves differently on a virtual machine than on a physical host. VMware-detecting features are sometimes built directly into the malicious program, and are sometimes added by a third-party packing utility. (A packer is a utility that modifies the original progral to conceal its strings, disable debuggers, detect VMware, and so on.)

We recently encountered a malicious program that was packed with a commercial packer called Themida. (Thanks for the heads up, Johannes!) This packer includes support for virtual machine detection, as you can see in the screen capture below:

• Implement a proxy server to filter outbound port 80 traffic. This is a good idea anyway as it may help you to implement additional filtering for web traffic as well.
• If you suspect an IRC server on port 80 in your own network, a quick scan with nmap can help:

nmap -A -p 10.0.0.0/24   (The '-A' option will look for service banners)

Interesting ports on 10.0.0.a:
PORT   STATE SERVICE    VERSION
80/tcp open  tcpwrapped            <--- expect this from devices 
                                        using web admin interfaces.

Interesting ports on 10.0.0.b:
PORT   STATE SERVICE VERSION
80/tcp open  http?                 <--- this server is running apache
                                        with customized headers.

Interesting ports on 10.0.0.c:
PORT   STATE SERVICE VERSION
80/tcp open  irc     ircu ircd     <--- this server is running IRC!
Service Info: Host: megaserver

• implement a snort rule to look for IRC traffic on port 80. Snorts 'chat.rules' has a number of rules to detect IRC, but they are limited to port 6666:7000 by default. You could try some of them to see if they work for you. But the way they are written could easily cause false positives. A slightly improved rule:

alert tcp any any -> any 80 (msg:"irc traffic on port 80"; 
     flow: established, to_server; content: "NICK "; depth: 5;)

• Do not forget to report such trouble back to Microsoft as well, it's the best way to get them to do something about it, and that kind of support is free.
  In the US call 1-866-PCSAFETY.
  Other coutries need to look it up on the Microsoft website, but it should be free just as well. [Fill in the country and then look in the column to the right]
  
• Do not wait for others to go first. We're all interested in not being the first ones to hit the bump in the road. Unfortunately this results in increasingly longer periods of just waiting and being exposed to the bad guys. Those bad guys are not waisting a second in getting their exploits out there, either actively using it, either selling the exploit itself.
  

Overview of the November 2006 Microsoft patches and their status.

--
Swa Frantzen -- Section 66

• Allows group policy to control WPA2 settings.
• Allows networks in the preferred network list to be set as broadcast or non-broadcast. Setting all to broadcast prevents the computers from leaking the list of preferred networks when they do not find one in their list.
• 'parked' wireless cards are given encryption. Parking a card is according to Microsoft: "Wireless Auto Configuration may create a random wireless network name and put the wireless network adapter in infrastructure mode.  In this situation, the wireless adapter is not connected to any wireless network. However, the wireless adapter continues to scan for preferred wireless networks every 60 seconds".
  They go on with: "Some wireless network adapter drivers may interpret this parking operation as a request to connect to a wireless network. Therefore, these drivers may send probe requests in search of a network that has the random name. Because the parking operation passes no security configuration the driver, the random wireless network might be an open system-authenticated wireless network that uses no encryption. An observer could monitor these probe requests and establish a connection with a parked Windows XP wireless client".
  Now encrypting will surely help, but it does feel funny to let it sit there configured randomly while there is no use for it doing anything.
• Stop trying to connect to ad-hoc networks in the preferred network list.
  

Body of the loan offer 1:
"Thank you for your loan request, which we recieved yesterday,
we'd like to inform you that we are accepting your application, bad credit ok, We are ready to give you a $236,000 loan for a low month payment.

Approval process will take only 1 minute.

Please visit the confirmation link below and fill-out our short 30 second form.

Body of load offer 2:
"Thank you for your loan request, which we recieved yesterday,
we'd like to inform you that we are accepting your application, bad credit ok, We are ready to give you a $234,000 loan for a low month payment.

Approval process will take only 1 minute.

Please visit the confirmation link below and fill-out our short 30 second form."


Header of the First email:

Received: from 105.12.117.87.donpac.ru (105.12.117.87.donpac.ru
[87.117.12.105])by mail.notmydomain (8/8) with ESMTP id
kADFeJhv023656for <NotMyEmail@notmydomain>; Mon, 13 Nov 2006 08:40:29 -0700 (MST)

Received: from 66.179.38.137 (HELO smtp3.harrisinfo.com)    by notmydomain
with esmtp (J.E5*P/Y,8@ XS,;)    id D2,237-/3J2I3-OH    for
NotMyEmail@notmydomain; Mon, 13 Nov 2006 15:34:57 -0180

From: "Meagan Howell" <akstcharrisinfomnsdgs@harrisinfo.com>
To: <NotMyEmail@notmydomain>
Subject: We accepted your loan request
<SNIP> 

Header from email 2:
Received: from ploy-433d4dd4c8 (ppp-124.121.125.171.revip2.asianet.co.th
[124.121.125.171])by mail.notmydomain (8/8) with ESMTP id
kADErFu6026071for <NotMyEmail@notmydomain>; Mon, 13 Nov 2006 07:53:19 -0700 (MST)

Received: from 194.2.3.145 (HELO smtp.oleane.net)    by notmydomain with esmt
(439O>US,1*K0 5L2V)    id ,5X4+H-IM**Y5-T'    for NotMyEmail@notmydomain;

Mon, 13 Nov 2006 14:53:18 -0420
Message-ID: <01c70733$74a1dd40$6c822ecf@akstcapcmmnsdgs>
From: "Marquita Rosenberg" <akstcapcmmnsdgs@apcm.fr>
To: <NotMyEmail@notmydomain>
Subject: Your loan request approved
<SNIP>

  Q  -> DNS: Query for NS sans.org
  Q  -> DNS: Query for A sans.org
DNS  -> Q  : Response, Server failure
DNS  -> Q  : Response, Server failure
  Q  -> DNS: Query for MX sans.org
DNS  -> Q  : Response, Server failure
R -> DNS: ICMP Admin prohibited
R -> DNS: ICMP Admin prohibited
R -> DNS: ICMP Admin prohibited

Internet Protocol, Src: 213.154.224.17 (213.154.224.17), Dst: 70.91.145.9 (70.91.145.9)
    Total Length: 65
    Identification: 0x4aa5 (19109)
        .0.. = Don't fragment: Not set
    Time to live: 47
    Protocol: UDP (0x11)
User Datagram Protocol, Src Port: 63417 (63417), Dst Port: domain (53)
    Length: 45
Domain Name System (query)
    Transaction ID: 0x3180
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 1
    Queries
        sans.org: type NS, class IN
            Name: sans.org
            Type: NS (Authoritative name server)
            Class: IN (0x0001)
    Additional records
        : type OPT
            Name: 
            Type: OPT (EDNS0 option)
            UDP payload size: 4096
            Higher bits in extended RCODE: 0x0
            EDNS0 version: 0
            

I removed some lines from the tethereal output. The packet looks "normal" withe the one exception of EDNS0 being used. EDNS0 is used to indicate to the receiving DNS server that the querying DNS server is able to receive more then 512 bytes of the response as a UDP packet. In this case, its 4k. A bit large, and frequently large EDNS0 packets are used to increase the amplification f or denial of service attacks.

Couple other things if you compare the packets:

• the IP ID is incrementing. So these appear to be the only packets sent by the 'Q'.
• the source port is constant... odd...
• the DNS query IDs appear random.

Internet Protocol, Src: 70.91.145.9 (70.91.145.9), Dst: 213.154.224.17 (213.154.224.17)

    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
User Datagram Protocol, Src Port: domain (53), Dst Port: 63417 (63417)
    Length: 45
    Transaction ID: 0x3180
    Flags: 0x8002 (Standard query response, Server failure)
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 1
    Queries
        sans.org: type NS, class IN
            Name: sans.org
            Type: NS (Authoritative name server)
            Class: IN (0x0001)
    Additional records
        : type OPT
            Name: 
            Type: OPT (EDNS0 option)
            UDP payload size: 4096
            Higher bits in extended RCODE: 0x0
            EDNS0 version: 0
            Z: 0x8000
                Bit 0 (DO bit): 1 (Accepts DNSSEC security RRs)
                Bits 1-15: 0x0 (reserved)
            Data length: 0

The response from my DNS server: well, nothing unusual here. I would like to point out that no fragmentation is used (well, there is no need to). The 'DF flag is set. The IPID is set to 0, which is typically for recent Linux kernels if the DF flag is set.

Internet Protocol, Src: 213.136.31.102 (213.136.31.102), Dst: 70.91.145.9 (70.91.145.9)
    Total Length: 56
    Identification: 0x0000 (0)
    Time to live: 50
Internet Control Message Protocol
    Type: 3 (Destination unreachable)
    Code: 13 (Communication administratively filtered)

[decoded embedded packet from ICMP message]
 Internet Protocol, Src: 70.91.145.9 (70.91.145.9), Dst: 213.154.224.17 (213.154.224.17)
        Total Length: 16640 (0x4100)
        Identification: 0x0000 (0)
        Flags: 0x00
        Fragment offset: 512
        Time to live: 50
        Protocol: UDP (0x11)
        Header checksum: 0xbb7b [incorrect, should be 0xba7c]
            Good: False
            Bad : True
        Source: 70.91.145.9 (70.91.145.9)
        Destination: 213.154.224.17 (213.154.224.17)
    Data (8 bytes)

0000  00 35 f7 b9 00 2d 3b 8b                           .5...-;.

Now this is where the "blast from the past" shows up:

Fragment offset 512Bytes. If you look at the Flag/Fragment offset bytes: 00 40.. flip them and you end up with '40 00' or: no fragment offset and 'do not fragment' flag set. hm... interesting...

Now if we just forget for a moment that this packet claims to be fragmented, we see that the "payload" is actually a normal UDP header: Source port 53 and Destination port 63417. This is the same port we had as a source port earlier. So if you ignore the fragmentation issue, this kind of looks like the result to the DNS response we sent earlier. Even the TTLs work out right! But then again... the size of the packet is HUGE. Looks like another byte-order issue: a size of 0x41 (65 bytes) is much closer to the size of the packet we sent.

We had a case a couple years ago with a similar byte order issue. But this is odd in the sense that the spoofed packet appears to be a direct result of the real packet. The spoofed packet is very close to the real packet. Maybe its not actually spoofed but just "mangled" by some kind of in-line device?

• Only effects the wireless driver, not the broadcom wired cards.
• The resepective file is BCMWL5.SYS Version 3.50.21.10 (this is the version pointed out as vulnerable. Others may be vulnerable as well).
• Only Linksys published an official update at this time.
• Other vendors have later versions of this file available as patches. It is not clear if they patch the problem or not.
  
• The problem is triggered by an overly long SSID
• the MOKB project published a metasploit module to ease exploitation of this problem.

After our morning vulnerability briefings, I often receive emails from our support engineers asking: "when will Microsoft release a patch for this?"  Answers such as "it depends" and "probably next Microsoft Tuesday," although technically accurate, do not provide much value to them.  A real answer is important to them; it impacts their planned maintenance cycles and can have a real dollar impact to the firm.  How do you really answer that question?

     First, what kind of answer is required?  For this particular example, a "yes" or "no" answer to "Will it appear in the next monthly release?" is acceptable, but a level of confidence should accompany it.  "Will it be released before schedule?" is also a key follow-on question.  So a good answer would be: "This patch in 95% likely to appear in next month's release, an early release is unlikely."

     If you don't provide a level of confidence, you really can't improve your process.  Vague terms like "not likely," or "probably," are not measurable.  If you can't measure your intelligence process, you can't improve it.  This is why confidence levels and feedback are so important. 

     To develop this answer I use a conceptual model.  This process became a lot easier once Microsoft moved to their monthly release schedule.  Given the past year's release data, I stand a reasonable chance of predicting accurately.  A key element is our knowledge base, which contains known vulnerability information, patch release dates, and details of the patch.  I expect Bayesian analysis could be as accurate as I am.  Some of the key findings from the model are:

• Microsoft will release an out-of-band patch only if a third party has released an unofficial patch, and that patch involves a change more involved than a kill-bit.

• Microsoft will release a patch on the next release date if the fix involves only a kill-bit.

     Try this at home/work/office yourself.  There are 5 unknowns coming out next week.  Make your guesses what will be released.  The kill-bit for the XML Core Services issue has already been announced.  Be sure to keep score, shooting for that 95% confidence rating.  For issues where you're not 95% confident, list what information you need to improve that rating.  That's how you improve your process.  For bonus points, train a learning algorithm (Bayesian, neural network, automata, etc.) to play along.

• 1 patch affecting "XML Core Services", rated "critical", will require a reboot
• 5 patches affecting Windows, maximum rating "critical", some of these will require a reboot
• New "Malicious Software Removal Tool"
• 2 additional "non-security high-priority updates" will be released, but only on Microsoft Update and WSUS

Frame 1 (60 bytes on wire, 60 bytes captured)
    Arrival Time: Nov  8, 2006 10:46:21.288548000
    Time delta from previous packet: 0.000000000 seconds
    Time since reference or first frame: 0.000000000 seconds
    Frame Number: 1
    Packet Length: 60 bytes
    Capture Length: 60 bytes
    Protocols in frame: eth:ip:data
Ethernet II, Src:  (xx:xx:xx:xx:xx:xx), Dst: (xx:xx:xx:xx:xx:xx)
    Type: IP (0x0800)
    Trailer: 000000000000000000000000000000000000
Internet Protocol, Src: xxx.yyy.171.21 Dst: aaa.bbb.181.18 
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 28
    Identification: 0xdf49 (57161)
    Flags: 0x00
        0... = Reserved bit: Not set
        .0.. = Don't fragment: Not set
        ..0. = More fragments: Not set
    Fragment offset: 1472
    Time to live: 112
    Protocol: TCP (0x06)
    Header checksum: 0xXXXX [correct]
        Good: True
        Bad : False
    Source: xxx.yyy.171.21
    Destination: aaa.bbb.181.18
Data (8 bytes)

0000  75 37 68 4c 52 65 2b 4d                           u7hLRe+M

Sure, in particular after I write this article, attackers may catch on. But there are many ways to mark a form field as "invisible". You can randomize the names of your form fields to further confuse them. In short: you again increased the workload on the spammer without affecting the regular user. For a sample, just take a look at our contact form. We received only about 3 or 4 pieces of spam after implementing this last week. Usually we received dozens of pieces of spam a day.

Once again we have a nasty little email circulating that is trying to scam the unsuspecting Internet users out of their hard earned dollars. The email purports to have a product that can “guarantee that all of your banking transactions are completely secure”.  In reality this scumware does anything but…

They are selling a VPN solution and would love to have you fall for it er…  purchase it. (Adding to their little bot I am sure).

As a matter of fact when I tried to go to the web site I got a warning from my filter that the site was a known spammer site.  

The requirement for domain name holders to provide a working abuse@example.com email address comes not only from tradition, but also from RFC 2142. It's interesting to note that that RFC doesn't address itself to just ISPs, it goes for any entity on the Internet.

So do your postmaster, info, NOC, hostmaster, webmaster, abuse, security, ... email addresses actually work ?

Having been on both sides of the fence when it comes to abuse@isp.net let's look at some misconceptions:

• "let's use an auto-reply": auto-replies are in my book evil. But they are also an insult to somebody trying to do their best in making the Internet a better place and reporting on such a thing. Sure submitters will appreciate a short note that their complaint has been dealth with and thanking them for their time, but do so after you processed it. Worse are auto-responders that give a whole bunch of instructions on how to submit things that just aren't relevant.
  
• "filter the spam": I've seen an abuse departments demand a copy of the spam be attached to the email and running a spam filter that bounced the message due to it being detected as spam if the spam was attached. Guess how many valid spam reports they got.
• "form letter reply": While I think form letters are in fact good for responding to abuse notifications, you need a bunch of them, not just one. E.g. I've received form letters asking for an attachment of the spam I was supposedly complaining about while submitting a defaced website hosting some malware to an ISP. The range of complaints is always wider than what your form letters can encompass and submitters have better things to do than wade trough overly long form letters anyway. So keep them short and to the point.
  
• "automate it": While there are abuse reports that can be automated (e.g. the motion picture lawyers use a xml attachment that can easily be automated to trace back your peer2peer copyright abusers), trying to widen this to encompass all complaints just will not work for the same reason as your form letters don't always work.
• "web form": The horror method for reporting entities. You write up everything they need in a neat email and get a rude auto-reply to please use http://obscure.web.example.com/silly.form instead.
  
• "abuse is helping users/customers": Abuse is actually more the one wielding the whip, kicking out unwanted elements based on the AUP (Acceptable Use Policy) or ToS (Terms of Service) or other policies. Helpdesks typically are streamlined to help users to take care of customers. Mixing the two roles into one group can cause abuse to become very inefficient at kicking out the unwanted elements. Abuse helps the outsiders getting the users/customers under control.
• "abuse kicks out our good customers": Yes, abuse will trigger processes to kick out misbehaving customers. But they aren't the nice customers and if you do not deal with those misbehaving customers your really nice customers as well as yourself will face consequences as your neighborhood is fast becoming a bad neighborhood on the Internet.
  

• Handle the incidents, make sure the users/customers know you are strict as it leads to less abuse. Have policies that have teeth and can bite, and let them work even when external. This will result in a very short time in less incidents to handle as once you take a few harsh measures you eliminate the really bad apples and the word will spread so that the rest starts to behave a bit.
• Have forms letters for:
• Thanking submitters and letting them know it's been dealt with (where I live you cannot -legally- give details of what you did).
• Asking for more details, but be specific what you need extra for the case at hand.
• Warning users/customer they are breaching policy
• Escalating incidents to be investigated further
• If you get easy to automate requests: sure process them, but keep a human supervision to it to make sure it doesn't get abused itself.
• Do not filter the abuse email with anti-spam software, people will forward spam messages originating from your users/customers, so you need to let it in. Yes, you'll have to delete the regular crop of spam.
  
• Handle the queue manually. Somebody put time into writing up the compliant, you should too.

• Somebody reporting a defaced website spreading malware: "Thank you for submitting a report to the [X] Network Abuse Department. Unfortunately, your submission does not contain sufficient information to determine the nature of your issue.  Evidence to Abuse should always include at least the IP address of the offending party and a valid timestamp, which includes time, date and timezone."
  If you host the website or if your customer hosts it, they will have better timestamps then the submitter. You really need to accept incidents and work with them on a minimal basis, if you need more you can always ask for more later on, but e.g. in this case the website is defaced "now", just check it and act on it. [BTW: checking a website distributing malware: take care with that browser ...]
• "Thank you for submitting a report to the [X] Network Abuse Department. Unfortunately, we are unable to investigate the email you forwarded because it does not appear to have originated from the [X] network." Well perhaps the automation missed the ball completely here. There was an attached email (actually an auto-reply from the organization itself). There are two problems however:
• The assumption that any attached email is what is being complained about. What if it was (as in this case) a clarification of the failing reporting process.
• The email did originate from the organisation itself. Interpreting email headers is not easy. If you cannot detect normal email headers reliably, don't even try to interpret spammed email headers (spoofed information).
  

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\
    {88d969c5-f192-11d4-a65f-0040963251e5}]
"Compatibility Flags"=dword:00000400

Microsoft Security Advisory (927892)

Vulnerability in Microsoft XML Core Services Could Allow Remote Code Execution

One of our readers wrote in to tell us that they are experiencing alot of traffic on TCP port 48318.  They even sent us a pcap of the traffic so we could take a look.  Unfortunately the pcap only contained inbound SYN packets, and outbound RST packets.  

The Source IP's were from totally different countries, and unique in makeup.  Some packets could be from Windows Machines, (judging from TTL, options..etc) and some don't appear to be.

Taking a look at our port graph here...



Clearly we have something going on.

So we need some packets.  Don?t bother sending us just SYN packets, we?re going to need at least some 3 way-handshake stuff. 

Now.  We are NOT telling you to allow this port through the firewall, lets just get that straight.  But if you were in an operational environment where you may be allowed to get us a dump of the traffic with PERMISSION, then that would be great.

Joel Esler

There is again a Proof of Concept Virus for Mac OS X. To be honest the virus is no big deal in itself. But it is yet another warning for a lot of parties involved.

As we said before the ability to have viruses and all sorts of other malware is inherently available in all modern operating systems, Mac, Linux, BSD, ... included.

It is a warning to get antivirus protection for those Macs, even if the shopkeeper told you you do not need it, even if there are no viruses in the wild today, even if it's hard to buy it, and even if the antivirus vendors seem not to know what they talk about like in the image below (highlights are mine):