Archive for May, 2008

Greetings from (sorta) sunny Melbourne, Australia! We’re the newest addition to Microsoft’s Security Research and Response global team. In arbitrary seating order we have: Jakub Kaminski, Scott Molenkamp, Hamish O’Dea, Heather Goudey, Raymond Roberts, David Wood, Chun Feng, Oleg Petrovsky, Hermineh Tchagatzbanian, Hil Gradascevic and Matt McCormack. In the same order we have: Skinny Latte w/ 1, Espresso, Skinny Latte w/1, Skinny Latte w/1, Latte w/1, Hot Chocolate, Latte, Cappuccino, Cappuccino and Latte. Try carrying all those coffees at once – it’s not easy.

After our inclusion of the Win32/Nuwar (alias Storm) family last September (http://blogs.technet.com/antimalware/archive/2007/09/20/storm-drain.aspx) and the dent we put in the Win32/Cutwail (alias Pandex) network in January this year, we thought we’d continue the anti-spam motif by targeting the Win32/Oderoor (ominously dubbed ‘Kraken’) network. Research shows botnets with cooler names are way scarier.

“Spam networks you say?” “Why spam networks?” – Oh, convenient question random person! Glad you asked! In our recently published Security Intelligence Report (http://www.microsoft.com/security/portal/sir.aspx *) it was found that around 96% of inbound messages to Exchange Hosted Services were blocked because they had spam on them. Spam all over them. The SIR also found that approximately 80% of all spam that (tries to) go through Hotmail is from a botnet of some sort. I know it’s hard to believe, but those are graphs and charts people. Graphs with bars. Bars of truth. Research shows that statistics never lie.

Since the bad guys aren’t paying for the hardware or bandwidth, they can send spam to their hearts content. All that’s needed is one in every few billion emails to fool someone into buying the pills (which don’t work by the way...) or giving up their bank account details (some nice man from Nigeria emailed them personally!) to make it a worthwhile industry.

In case you weren’t aware, the always interesting Joe Stewart over at SecureWorks recently published a list of the top spam botnets (http://secureworks.com/research/threats/topbotnets/). As is to be expected our old friends Nuwar and Cutwail were there, along with THE KRAKEN. Joe’s estimate was that the size of the network was around 185,000 nodes, and spewing around 9 billion emails per day. Research shows that 9 billion emails is, in fact, a large number of emails. There was some contention over at the Damballa (http://www.damballa.com ) camp, who thought the network was more like 400,000 nodes strong. Either way, that is a lot of infected machines.

Being the helpful lads they are, the guys over at DVlabs (http://dvlabs.tippingpoint.com/) thought they’d get to the bottom of the ‘Mystery of the Disappearing Botnet Nodes’ and take a peek at the network from the inside (http://dvlabs.tippingpoint.com/blog/2008/04/28/kraken-botnet-infiltration). Whilst this doesn’t really help us with the number estimate, they did manage to obtain 65,000 unique infected IP addresses, so now we only have to account for the other missing 125,000-335,000 nodes. With so many nodes around you’d figure people would be tripping over them all over the place. Sadly not. :(

When we first identified Oderoor as a distinct family back in September 2007, links to the bots were being spammed through IM and the files themselves were encrypted to the wazoo (well, they still are doing both of those things). It didn’t take long for us to get a hold of the situation, but for the most part vendor detection remained very low. For months afterwards, we were one of the few vendors to be detecting new variants as they came in (turns out we had got samples from as far back as May that year, however the encryption was fairly rudimentary). As is to be expected, the family shone brightly on our radar and was being considered for MSRT inclusion at around the time that Joe published his article. So it all worked out rather nicely :).

Finally, our perspective on the Win32/Oderoor botnet; what MSRT has found. The numbers tend to go up and down, so I’ve included the first week wrap-up. Extrapolating (since we know how these things tend to pan out), we can probably expect in the order of 300k distinct machines this month that were cleaned of Oderoor.

So our size estimate is somewhere in the middle of the SecureWorks and Damballa numbers. Of course our numbers are not the definitive answer. Whilst we run on 500 million machines and can get a pretty good idea of what’s going on, there are still a lot of machines out there that aren’t running MSRT; possibly because they don’t have automatic updates turned on.**  

Question: How do these numbers compare to ‘Storm’ in the first few days?

Answer: Pretty close :)

If we take a look at the first week removal results from Nuwar, we can get an idea of the relative size of the network. The Cutwail removal numbers are included to complete the spam trio. I’ve also included the graph because graphs are impressive.

So it would appear the Win32/Oderoor network is slightly smaller that the Win32/Nuwar network – around the 80% mark. It should be noted that the Nuwar numbers are a lower-bound (due to the way we detect them), so in reality it is likely slightly smaller again. The detections per machine are higher for Nuwar because there was/is more components than Oderoor’s standalone executable. Speaking of the standalone executable - as tends to happen with these things, the Oderoor authors put out a new version the day after MSRT’s release: Backdoor:Win32/Oderoor.gen!E. We love these games of cat and mouse. Vendor detection is still a bit sketchy.

And how well did Oderoor fare with respect to the other families in MSRT this month? It made the top 4 which is very impressive considering the other types of malware that are being targeted:

We’re in contact with the guys over in DVLabs who are going to take a look at their data to see if they noticed a drop from inside the network after MSRT’s release. We’re eagerly awaiting a post on their blog (http://dvlabs.tippingpoint.com/blog).

So was that Kraken botnet all it was Kraked up to be? I think yes. If we look at hype vs MSRT results, this botnet received a lot less hype than Nuwar’s network, but achieved pretty high infection numbers. If anything, it might even be understated. However hype is dependent on a botnet having something that makes it unique and interesting, such as Nuwar’s distributed peer-to-peer architecture. Encrypted communications over port 447 are ok but peer-to-peer is better I reckon. So perhaps it was just the right amount of hype. Juuuust right.

All Kraked out,

Matt McCormack

* - watch the Bret and Vinny show while you’re there. Vinny is our boss. He’s alright.

**- Seriously, running un-patched computers and being connected to the Internet is asking for trouble. It really is such a bad idea. It takes next to no time for an un-patched machine to get infected by some worm or another; this is one of the reasons we release MSRT to try and clean up the eco-system.

Google has released version 0.2 of libkml, an open source library for serializing and deserializing KML files. libkml now uses a memory management scheme based on "smart pointers", and has deprecated the use of SCons. On Linux and Mac OS X it now use the traditional automake, and on Windows Microsoft Visual Studio. The "smart pointer" scheme presently restricts support for some alternate language bindings, so libkml 0.2 can only be called from C++, Java, and Python. Version 0.1 also supported PHP, Perl, and Ruby, and is still available in the subversion repository if you're interested. We plan on restoring the those bindings as soon as we can.

Check out the User Guide, and particularly the future development list.

// createkml.cc
// This program uses the KmlFactory to create a Point Placemark and
// prints the resultant KML on standard output.

#include 
#include 
#include "kml/dom.h"

// libkml types are in the kmldom namespace
using kmldom::CoordinatesPtr;
using kmldom::KmlPtr;
using kmldom::KmlFactory;
using kmldom::PlacemarkPtr;
using kmldom::PointPtr;

int main() {
  // Get the factory singleton to create KML elements.
  KmlFactory* factory = KmlFactory::GetFactory();

  // Create .
  CoordinatesPtr coordinates = factory->CreateCoordinates();
  // Create -122.0816695,37.42052549
  coordinates->add_point2(-122.0816695,37.42052549);

  // Create  and give it .
  PointPtr point = factory->CreatePoint();
  point->set_coordinates(coordinates); 

  // Create  and give it a  and the .
  PlacemarkPtr placemark = factory->CreatePlacemark();
  placemark->set_name("Cool Statue");
  placemark->set_geometry(point);

  // Create  and give it .
  KmlPtr kml = factory->CreateKml();
  kml->set_feature(placemark);

  // Serialize to XML
  std::string xml = kmldom::SerializePretty(kml);

  // Print to stdout
  std::cout < < xml;
}

The engineers who worked on it put a lot of thought into making it fast and light weight. However, it is an alpha release. We really would love to have comments and feedback on it, both in the KML Developer Support forum and in the libkml issue tracker.

When we launched the map editing tools in Google Maps, the reaction of developers was "This is cool, but how can I use it on my own site?" As someone who was originally drawn to Google in part because of the Maps API and the great developer community around it, I committed to making the My Maps tools useful for developers on their own sites.

Today, I'm pleased to announce that our user interface functionality for editable polylines and polygons is now part of the Maps API.

Say, for example, that you have a GPolygon you want users to be able to edit. Simply call GPolygon.enableEditing() and the poly will have draggable edit control vertices when the user mouses over it. To later make it non-editable, call GPolygon.disableEditing().

We've also exposed additional events for GPolygon and GPolyline so that you can easily mimic the MyMaps behavior (in mashups or Mapplets) by calling enableEditing on "mouseover" and disableEditing on "mouseout". To find out when the user makes an edit, listen for the "lineupdated" event. And if you want users to be able to draw a new GPolyline completely from scratch, just use enableDrawing as shown below:

var polyline = new GPolyline([]);
map.addOverlay(polyline);
polyline.enableDrawing();

Every click on the map will add a new vertex to the polyline until the user double-clicks or clicks again on the last vertex. You can also call enableDrawing to lets users append vertices to either end of an existing polyline. And just because everyone likes pretty colors, we exposed methods to let you change the style of a polyline or polygon: setStrokeStyle and setFillStyle. Have fun, and let us know what you think in the forum.

Here at Google, we receive a lot of feature requests - and it feels great every time we fulfill one of them. The ability to utilize the power of Google Maps from Flash is one of those requests that has been popping up on blog posts and other forums since the beginning of time (or more accurately, the beginning of the Javascript Maps API). Over the past few hours, I've had the enjoyment of finally seeing this particular feature request - a Maps API for Flash - come to fruition. Tiredness will grab me soon, no doubt. If you're one of the first readers of this post, rest assured that I'm unlikely to still be awake: long hours have been worked; pre-launch nerves have jangled. Now it's time to let our baby loose into the world and see how the developer community will embrace it.

So, what do I like about the API for Flash? Smoothness and speed are a big part of it. We've designed it so that Flash graphics can be used for each tile layer, marker and info window - opening up possibilities like dynamic shading, shadowing, animation, and video. When the user zooms the map, magnification changes happen smoothly and place names fade in. After the user drags a marker, it gently bounces to a halt. Generally, Flash allows for much greater embellishment, and, well... "flashiness." I get excited just thinking about the creative ways developers might take advantage of having a Flash API for Google Maps.

What was one of our main design decisions for this project? We knew that version 1 of any software project is not perfect, so we opted to split the interface and implementation. As a result, you can build against the current version of the API, and as we add enhancements and tweaks, your website benefits automatically from each update. When you wish to take advantage of new API functions, only then do you need to download the latest API and rebuild.

What does it look like? We've played with it, thrown our ideas in, and also worked with outside companies to see how they use the API. It's been a pleasure to see some of the demos that have come back. Here's one from AFComponents that shows some of the possibilities:

When I first joined Google in Sydney, I got to hear about the experience of the Maps team when they first watched the traffic and the buzz build for the launch of Google Maps. Well, now I'm ready to experience that with this new API. Do send us feedback, we're looking forward to it.

Today, I’m happy to announce an early beta release of an Internet Explorer version of our del.icio.us bookmarks extension. For the first time our Internet Explorer users will enjoy most of the best features of our new Firefox extension. We’re very excited about this release, as we have many users who use Internet Explorer as their primary browser. Since there are some differences between Internet Explorer and Firefox, the two versions are not exactly the same, but you’ll find many of the same great features like the del.icio.us Sidebar and Toolbar. Here’s an overview of the IE features.

• Near instantaneous searching with very large accounts (over 10K bookmarks)
• Full del.icio.us sidebar and toolbar implementation with bookmark sync and typedown search
• Toolbar indicators for new network activity and links for you
• Works on IE6, IE7, and IE8 beta on both XP and Vista

Interested? Download it here.

Since this release is so new, we’ve also created a Yahoo! Group for downloading and discussing the Internet Explorer release. Go to http://groups.yahoo.com/group/delicious-ie-extension to sign up. In the group we’ll gather your feedback and share the release notes for each version. We’ve been using it every day in the del.icio.us tagmines for a few months now, but that doesn’t mean that we’ve found all the bugs. Just like the Firefox 3 release, many of the features and interface choices are experimental and may change before we officially launch. As always, we’re eager to hear your feedback on the add-on.

In other news, we’re all humbled by the large and positive reaction to our Firefox 3 beta extension release announcement a couple of weeks ago. Thanks to everyone who tried our extension out, especially those who submitted bugs. This feedback is enormously helpful as we work towards a final release of that extension.

Nick Nguyen
Senior Product Manager, del.icio.us

  posted by Dharmesh

Greetings Messenger fans –

As some of you noticed, we had a problem from Friday night to Saturday morning where our Messenger service was incorrectly blocking some legitimate IP addresses.  We sincerely apologize for any difficulties this caused our users.  And we want to thank those of you that reported this problem to us so that we could quickly fix it.  Because of your help, the incorrect block was only in place for a few hours. 

As you can imagine, we are very serious about our efforts to block virus, malware and other harmful URLs from being passed on to our users.  And we're continually working to improve this process so that we can keep our users safe without having a negative impact on your Messenger service.

There have been some pretty outlandish speculations on what happened so I'd like to give you some facts about our process for trying to block unsafe URLs and about what happened Friday night:

• There are a number of factors that can be used to determine whether a URL is potentially harmful: number of times a URL is sent, the frequency of the URL being sent, the number of accounts the URL is sent from, manually checking the URL, comparing with other "block lists", etc.
• When a URL is deemed harmful, a block can be instated for a specific URL (i.e. www.<domain>.com/<page>) or an entire domain (i.e. *.<domain>.com)
• This entire process for Messenger is managed by a 3rd party that is a Microsoft partner
• On Friday, Microsoft did not request to block any of the URLs that were accidentally blocked
• The blocks were made by our partner as a result of their process to block harmful URLs
• We are still investigating the specific reason our partner made these incorrect blocks and we will work with them to improve their process for detecting harmful URLs while not blocking safe ones

As always, we're open to feedback on how to make Messenger an even greater service.  And again, our apologies to the users that were impacted by this.