UDP/4081 Spike

Published: 2006-11-11
Last Updated: 2006-11-11 19:18:12 UTC
by Kevin Liston (Version: 2)
0 comment(s)
A diary-reader, Ned, reports a spike in UDP/4081 activity.  The reported source is located in China.  He did not have any captured packets, just firewall logs.  I'm 95% certain that this is messenger/pop-up spam.  I'd like to task the informal network Echelon system we have (in the form of our readers) to see if anyone can confirm this guess with a captured packet.

UPDATE: Florin has provided a capture from 09-NOV-2006 and from today confirming the Spam theory.  Thanks!
0 comment(s)

Broadcom Wireless Vulnerability

Published: 2006-11-12
Last Updated: 2006-11-12 01:09:18 UTC
by Johannes Ullrich (Version: 2)
0 comment(s)
The "Month of Kernel Bug" project released an advisory with details about a bug in Broadcoms Windows driver for its Wireless card. The high/low points:

  • Only effects the wireless driver, not the broadcom wired cards.
  • The resepective file is BCMWL5.SYS Version (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.
So much for now. Expect updates as we learn more.

Go ahead and patch your driver with whatever version they offer. If you get a chance, test the exploit and see if it works against some of the later versions. Of course, take care when doing so. The "known to be fixed" version from Linksys is

Whenever you don't use your wireless network, turn off the wireless card. In particular if you are in a public space (airport, hotel).

Update: also see the ZERT advisory (no patch though. but the advisory explains why)

0 comment(s)

Predicting Microsoft

Published: 2006-11-11
Last Updated: 2006-11-11 18:05:20 UTC
by Kevin Liston (Version: 1)
0 comment(s)

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.

0 comment(s)


Diary Archives