0x01 graphic Microsoft Customer Teleconference on the Blaster Worm August 21, 2003 On This Page * [1]Mike Nash - introduction and agenda * [2]Overview of recent events * [3]Delivery of the MS03-026 Security Bulletin to customers * [4]Public release of exploit code * [5]Blaster worm discovered * [6]Microsoft next steps beyond Blaster * [7]David Treadwell - introduction and agenda * [8]Lessons learned and steps taken * [9]Details on Blaster worm and variants * [10]Mike Nash - protecting your PC Coordinator Good morning, and thank you all for holding. All participants will be on a listen only mode until the question and answer session of today's conference call. Also, this call is being recorded. Our speakers are Mr. David Treadwell, General Manager of the .NET Developer Platform team; and Mr. Mike Nash, Corporate Vice President of the Security Business Unit. Mr. Nash, you may begin. Mike Nash I want to thank all the participants on the call for taking the time to spend some time with Microsoft today talking about the Blaster Worm and Microsoft's patch, MS03-026. As Michele said, my name is Mike Nash, and I am the corporate vice president for the Security Business Unit at Microsoft. One of the key parts of my job is to focus on how we can do a better job across the company to improve the overall security of both our products and services for Microsoft. I do want to apologize for the delay in starting this call. We had a very large number of customers calling in and I wanted to make sure that we had a chance to get everybody onto the call before I began, so you'd all have the opportunity to hear all the comments from David and I, and really to make sure we have a chance to listen to you and take some feedback. As Michele also mentioned, I'm joined today by David Treadwell, who is the general manager of the .NET Developer team here at Microsoft. He's going to co-host this call with me. David is one of Microsoft's senior engineering leaders, and he has overall responsibility for DCOM, CLR and the .NET framework, and in particular is responsible for a lot of the work that was done to build the patch for MS03-026. As we begin the call, though, I also want to remind you that at the end we'll have a chance for questions and answers. Those of you who want to submit a question to us via e-mail, we have set up an alias. The alias is: sec_fdbk@Microsoft.com. Certainly, we are very interested in both your questions and your feedback that David and I will address at the end of the call. There are four things I want to cover on today's call. The first is an overview and history of MS03-026, the vulnerability and the Blaster Worm. I'll be covering that. David is going to spend some time talking about a deeper technical discussion about the vulnerability and the exploits and share with you really everything we know about the situation. Third, I want to be really clear with you and set expectations on what you can expect from Microsoft going forward. Then lastly, we'll reserve as much time as it takes for the Q&A for David and I to respond to any questions that you have and certainly to take any feedback. I do want to say that a lot of the work that's been done, in the case of Blaster, certainly has come as a result of great feedback that we've gotten from customers like you over the course of the last year and a half or so. Certainly coming out of the Slammer experience back in January, there are a lot of things that you helped us to identify, and I hope that you're understanding the number of things we have changed to make your experience better, or as good as it can be. I also want to really focus on starting by saying that we realize that there's a significant amount of pain that the Blaster Worm has caused to you and other customers around the world. We know that you depend on Windows technology, in particular, and Microsoft technology in general for your business and that we have definitely had an impact on that business. I also want to make it clear that we understand that in some sense, this pain is not just economic cost of responding to the worm, but the fact that many IT professionals like you had to work extremely long hours to both prepare for this vulnerability, once the patch was available, but also to deal with the active response to the exploit once the worm was first out in the public. I also want to be really clear that we know that you're under extreme pressure to get patches installed. We appreciate those continued efforts and want you to know that we're doing everything possible to reduce that pain, but if you have other ideas of things we should be doing, David and I are here very much to take that feedback to make sure those changes are made as expeditiously as possible. I also want to be very clear that we appreciate - and hope you appreciate - that this is a very egregious and malicious criminal attack against our customers. While we're very sorry about that, I also want you to know that we are working very closely with law enforcement and authorities to identify the individual or individuals responsible for this criminal act. I also want you to know that at the same time that we have been working around the clock since we first heard about the vulnerability back at the beginning of July, to make sure that we had all the teams in place with the right technology to help make sure we had both the fixes you need, but also an emergency response process, which includes people from our Product Support organization, from the Product Engineerings teams and from the Microsoft Security Response Center, to make sure that you have everything you need, as we've been focusing on doing whatever is necessary to get customers up and running and ideally to protect them from the vulnerability in the first place. One of the things that this worm makes very clear to me and to the rest of the executive staff at Microsoft, is that we need to spend even more time, devoting our time and effort and the resources around the company behind the Trustworthy Computing Initiative that Bill Gates announced back in January of 2002. Very clearly, that focus on security, privacy, reliability and business integrity is the right direction, but clearly this event reinforces to all of us that we have even more work to do. We've made a lot of progress, but very clearly there's more things we need to do, not only to reduce these vulnerabilities, but also new steps we need to take to make sure that our software is more resilient even in the case where these vulnerabilities exist. I want to make sure that we spend time talking about that at the end of the call in just a little more detail on some of the things that we're looking at. I also want to tell you that in addition to the focus on dealing with this particular vulnerability, making the fixes available, creating tools to correct and identify this vulnerability, we also have a team of senior engineers from across the company working very closely on some new approaches to make our software even more resilient. What I want to do is invite you to a call that we're going to be doing in a few weeks, where I can not only report back to you progress we've made around Blaster, in particular, but also spend some time reporting back to you on our thinking around new ways to make our software more secure. As I said, we have the most senior engineers around the company focusing on that task as well. We've talked to thousands of customers, literally in the last two weeks, and I and the rest of the executive staff have received direct customer feedback through mail, through personal discussions, and frankly through great forums like the one today. In addition, our product support service organization has fielded thousands of customer calls. We have heard very clearly that there are some top issues that we know you're facing. First and foremost is the desire that we build software with fewer vulnerabilities, that we increase the quality and timeliness of our patches when these vulnerabilities do exist, to reduce the complexity of the overall patching process, but it's also been very clear that we need to do more work to build more tools and better guidance for maintaining your systems. As a part of that also, I know there are some tools that we have built that we need to do a better job of being consistent in our communications around those, but also doing work to make sure you have more awareness around those tools. Lastly, specific to the Blaster virus, we've also heard patch availability for systems, older service pack levels of unsupported products was a problem. As a result, we have made a patch for MS03-026 available for Windows 2000 Service Pack 2 and for Windows NT 4.0 Service Pack 6a. In both cases the feedback was that we needed to extend support because there were so many customer systems that were out there. Although this was different than our standard support polity, we made the decision to make those patches available for those customers, and I hope that's helping. It's also very clear, we've gotten feedback that the MS03-030 patch that was released yesterday, is causing problems. Again, our goal is to make sure that when we learn about these new vulnerabilities, we get fixes out as quickly as possible. We're also doing a review of those components to make sure we can identify other areas. Lastly, the critical feedback here is that the Welchia/Nachi variants and the latest variant of the SoBig virus are causing new problems. We're very much aware of that. Again, both of these we consider to be malicious attacks. We're working with law enforcement. We're also working both to provide better content and tools to protect you, but also making enhancements to the tools we have out there already Clearly, a part of this also is working in the consumer space with Internet service providers to make sure that we can have them build the right configurations in their systems to help contain the situation. In terms of some things we've also done is we've addressed not only Blaster, but also its variants. We're working with vendors of line of business applications to make sure we have a high level of compatibility with those line of business applications and the patch. The scanning tools, we have heard, in some cases are causing false positives. We're working to address that. Also important to note, certainly some issues around different guidance being given by Windows Update and MBSA, and we'll have a chance to talk about that later on in the call this afternoon. What I'd like to do now is just establish a baseline in terms of what you all and I experienced over the last few weeks. What I want to do is go through and really start at the beginning and share with you some of the key information about what we've been doing during the four key periods of time related to both the security bulletin, MS03-026 and the Blaster Worm. The four phases that we're looking at are the time between when we were first notified of the vulnerability by the Security Research Group, Last Stages of Delirium. That was on July 1^st. That period ended July 16 when the patch was first available. The second period of time is the time immediately after releasing the patch before the time that there was a public release of the exploit code. That's the period of time between July 16 and July 25 of last month. The third period of time is the time between the public release of the exploit code on July 25 and the first discovery of the Blaster Worm on August 11. Lastly, the fourth period of time is work we've done since the first time that the Blaster Worm was discovered in the wild. As I said, let me start by talking about the history prior to MS03-026. It really did begin for us in the initial phase when we were informed by the Security Research Group, Last Stages of Delirium, on the first of July. They reported to us a vulnerability in the RPC/DCOM component of Windows. RPC is a core communications protocol used by many Microsoft products and by many third party products. RPC stands for Remote Procedure Call. The MS03-026 vulnerability is exposed through a mechanism called remote activation, where DCOM is accessed across the RPC protocol. The vulnerability affects Windows NT 4.0, Windows 2000, Windows XP and Windows Server 2003. As I mentioned, it was reported to us by a group called the Last Stages of Delirium, also known as LSD. The key thing we did at that time was to immediately activate our highest level of emergency response, run by the Microsoft Security Response Center. We literally had a team working around the clock from the moment we had the report from the security researchers to build, test and release a patch, and we did that within two weeks because we understood the importance of both having a patch available quickly, but also we wanted to balance the need to have a very high quality patch in a timely period. During the process, though, I also want to make you aware of the fact we did work very closely with the security researcher to follow through on what we call Responsible Disclosure Guidelines, and really the goal here is to make sure that they share information with us in a confidential way and then work with us to both develop and test the patch, and together, we go off and share information about the vulnerability and the patch. The real goal here is to make sure that while we get the fix out there and help them to get credit for their great work, we minimize the risk we put customers at. I want to thank the Last Stages of Delirium team for their responsible behavior through this process. Stage two really began for us on July 16 when we delivered the security bulletin, MS03-026, to customers. It included patches for all affected supported Windows versions. That includes Windows NT Server 4.0 Service Pack 6a. Windows NT 4.0 Workstation is not a generally supported product anymore, but we subsequently added support for that product because of the fact that so many customers were in that situation. The patch included support for Windows 2000, Service Pack 3 and Service Pack 4, and again, we later announced support of the patch for Windows 2000 Service Pack 2, again, based on customer feedback. The patch is effective for Windows XP, both in the gold or no service pack version, along with Windows XP Service Pack 1, and the patch also was available for Windows Server 2003. I do want to note that Windows ME is not affected and Win 9X versions, which are not supported, are also not affected. On July 17, we updated the bulletin as we learned more information about the potential exploits. I want to be clear that that update to the bulletin included more details about mitigation, new steps that we thought were important for customers to follow to protect themselves in addition to the ones that were in the original bulletin. Of course, the patch itself was the most effective way of protecting the customer, but I want to be clear that the re-release of the bulletin on July 17 was simply more guidance. The patch was unchanged, and the initial patch that we shipped on July 16 was effective even in light of the information and continues to be effective against Blaster and its variants. At the time, we also notified customers through our Security Notification Service. We have customers signed up for that service. We sent e-mail from Microsoft account teams to their contact at the customer. We also had our support teams and technical account managers in particular working directly with technical staff and security staff within our customer organizations to make sure things were well understood. We also spent a lot of time using the press to do outreach both to enterprise customers and to consumers, to make sure there was a high level of awareness of both the existence of the patch and vulnerability, but also the importance of this patch in particular getting high priority to protect customers of all sizes. Some of the examples of that outreach - and I'm sure a lot of you saw this through channels that you participate in - analyst briefings with Gartner, IDC, Meta and Forrester, a lot of proactive press with both the technical press and the business press. A PSS alert was sent out to all of our product support customers. We used our Microsoft Valued Professionals or MVPs in online communities, our support team, our Microsoft Consulting Services staff, essentially everyone at Microsoft who has any interaction with IT professionals. We made updates to all Microsoft Internet properties; Microsoft.com, MSN, etc., to make sure people were aware of this. We also issued a joint advisory with the Department of Homeland Security to make sure that customers - even ones that don't necessarily interact with Microsoft directly - had information about the situation. A lot of work was done on the consumer Web outreach to make sure that on the homepage of both Microsoft.com, MSN and other properties, that we had the right tools to help customers to be successful. A lot of work was done with security researchers, in particular Marc Maiffret, Russ Cooper and other security research firms. We spent time with them. I want to thank them for the great work they've done to reach out to customers to get people the best information about both the vulnerability and the exploits. One of the things that we got feedback from many of you coming out of the Slammer situation in January, was there was a need for us to have a much more efficient clearinghouse of information between Microsoft and Security Partners. So we've created something that we announced in April called the Virus Information Alliance, or VIA, and the key thing we did with the VIA partners was to contact them to let them know about the bulletin and also share with them information we had about the vulnerability, things including network traces, etc., so they could actually change their security products and train those products to help you protect yourselves from the potential of exploits that we envisioned back on July 16. Quite a bit of outreach down here with ... with Internet Security Systems and Foundstone, all who did a great job of helping to get the word out, but also to provide even more in-depth information about how to be secure. On July 25 an important milestone was reached when Exploit Code was first publicly released, really initiating the third phase of this process for us. X-Focus, which is a full disclosure security research group, published an exploit tool that would allow an attacker to run any software of their choice, any software of the attacker's choosing, on an unpatched system. Another full disclosure researcher published an updated version of the exploit tool and said that their real goal here was to make the tool more reliable. Very clearly there was a lot of community feedback that indicated the real possibility of this exploit code being used as the basis for a potential worm. As a result, we took the obvious step, which is part of our process, to heighten our efforts to get information out to customers. We repeated all the proactive communication around MS03-026, while at the same time upgrading our level of concern given there was now exploit code that was available publicly. We proactively did updated conversations with both analysts and press to make sure they understood the importance of this situation and worked with the Department of Homeland Security to release an updated advisory. At the same time, the Computer Emergency Response Team, or CERT, issued an advisory on July 31, very much in response to the existence of this exploit code. We worked with our security partners and vendors, and again, members of the Virus Information Alliance, to insure that not only had they gotten the guidance from us on how to make their products have the capabilities to detect and protect against these attacks, but to actually make sure that that protection was available. We also sent e-mail to all of our enterprise and smaller customers to make sure that they had information that they needed. All of our account managers were instructed to personally make contact with their customers to convey the increased level of risk, but also to explain that that level of risk had be increased because of the existence of exploit code. Of course, the Web sites were updated to make sure that they had a more forceful, more urgent advisory around the importance of installing MS03-026. Last week on August 11, very clearly we began the final phase. The Blaster Worm was first seen in the wild, and the Blaster Worm really attempts to do two things. The first, it replicates itself using the vulnerability that was corrected in MS03-026. At the same time, it was also designed to, at a specific time, to get attacking windowsupdate.com and in particular, to make sure that it really was focusing on trying to take down the site that we use to protect customers. I really want to emphasize, first of all, that there was never a successful attack against windowsupdate.com because we had the opportunity to take the steps to protect the system. The result of the Blaster Worm is, in some cases, systems, when they're infected, crashing during the attempt to infect the system. Also in the process of the infection, it can generate a lot of network traffic, in particular on customer networks, but also on Internet backbones as a whole. We also began to notice variants of the Blaster Worm within a few days. Again, the Microsoft Security Response Team continues to work 24x7 to, first of all, investigate the worm and its variants, to make sure we understood them, had protection, but also worked very closely with our partners to make sure that they had the information they need to make sure their tools were effective at protecting our customers. To provide even more security guidance for customers, to make sure you had the information you needed to protect yourselves, we used the Virus Information Alliance again to make sure that they could help not only build tools, but also to provide guidance, help and support to make sure customers were safe. We provided Blaster specific training for Microsoft Support personnel to make sure that people actually had information to help them make Microsoft an authoritative source to help you protect yourself wherever possible and remediate yourself wherever necessary. We have also been working with both Internet service providers and OEM's so they can help provide specialized guidance for their customers, so they can actually use their position and partnership with you to make sure that you have that protection. At the same time, I also want to emphasize we continue to monitor new developments and are dealing with things like the Nachi virus, the Nachi worm and SoBig that have become considerable issues for you and for us and the industry over the last couple days. To insure that we can be responsive and to help you through the critical period, I also want to be really clear that we've done a lot to increase our level of communication with customers, partners and home users. On some level, this call is an example of that, where not only users call to share with you the information about the vulnerability and the exploit and the steps we've taken, but at the same time use this call as an opportunity for us to listen to the issues that you're facing. Ideally with that feedback, we can do an even better job of responding to your needs. So I really appreciate the time on the call today, but also the openness that I know you'll have as we go to the Q&A section in a few minutes. We've created special edition newsletters. We really stopped all of our regular newsletters that we do electronically and made sure that we sent to all of the subscribers information about how to protect yourself. We've made sure that our Web sites have Blaster protection and remediation. Basically, all the homepages for Microsoft properties now link to specific information, as appropriate for consumers and enterprises, on how to be more secure. We have sent e-mails to customers of all sizes with specific guidance. We're also working with our partners to make sure they have the information they need, not only to protect themselves, but also to have them protect our mutual customers to be more secure. We've also got a technical Web site, a WebCast rather, that's targeting both technical and home users with specific prescriptive guidance around Blaster. Of course, we continue to work with press and media to make sure that the right information is out there. We've also realized that we need to simplify overall the guidance around how customers can protect themselves in the case of Blaster, but frankly around protecting your PC in general. So we've actually launched an unprecedented "Protect your PC" campaign, which targets both home and business users. Really, the goal here is to raise awareness. I'm sure many of you saw some advertising we did in some daily periodicals over the last couple days. Really, the intent there is to make sure that people understand the importance of the situation, and we provide them a pointer to the guidance with clear steps on how to be more secure. We've also created specific guidance for customers of all sizes in general. The place to go for all users is www.Microsoft.com/security. For home users, we have created a new Web site over the last two days, the one that's really highlighted in this advertising. It's at www.Microsoft.com/protect. Of course, for IT professionals, www.Microsoft.com/technet/security, is the best place to go to get information around how you can protect the enterprise from this. In addition to having information around Blaster, in particular, there is really good content out there about how to do patch management and several scenarios on how to be more secure. We've also been working very hard to ensure that our ability to continue to provide information is very much there, so customers get the information that they need. We've increased number of phone lines worldwide. We also realize that even with more phone lines, we didn't have enough people available to respond to customer issues. So we both trained and redeployed personnel from around the company, particular members of the development staff, to help alleviate the load that our product support organization had, and essentially we have engineering staff from the Windows Development organization on the phone in front of support to make sure that customers have the best information possible. We've also done a lot of work to provide additional support through Online Community, including online newsgroups. We've also realized that there were some issues around our global Internet capacity. We've increased that capacity and contracted with several caching service providers to insure that we have uninterrupted access to Microsoft's corporate Web site, including Microsoft.com and Windows Update, to not only get you the information that you need, but also to make it easier for you to get the content, the data you need and the packet you need without ever having to be delayed. We built and released a scanning tool that helps you to scan your network from machines that are unpatched with MS03-026; the tool has received terrific feedback from many customers that have used it. It's been downloaded over a million times already. That said, we've also received some feedback on how to improve the tool, and in particular to reduce some of the false positives the tool had. There will be an updated version of this thing very shortly. Lastly, Microsoft is working with law enforcement, as I mentioned earlier, to investigate this attack and help identify the individual or individuals who are responsible for it, and we're working very hard to make sure that these individuals are apprehended and prosecuted to the largest extent of the law. We've mobilized all of our field personnel to raise awareness and to help resolve customer issues. Some of the industry partnerships we have worked on is working with Security Software Partners to make sure they have the network traces of the worm, to insure that the intrusion detection software detects not only Blaster, but its variants, but also information we can share with them to make sure that firewall configurations are more effective at blocking with it. We're working with OEM vendors to make sure that we immediately sticker all machines that include an end user focused security guidance, similar to what we have on the flash protect site. We're also working to make sure that OEM ships new machines with the patch installed. We're working with networking partners, such as Cisco, to put together prescriptive guidance for how to use their product to provide filtering and protection. As I mentioned briefly, we're working with ISP's to provide the guidance for them on how they can work with their customers to first of all, use the firewall more effectively, help them to get patched, but also in ways to use antivirus software to protect themselves. We're also working very closely with our ISP partners to make sure that they have all the information they need to use their infrastructure as part of the tools to filter and contain this worm, both for broadband and dial-up segments. We've also been doing a lot of work to generate new ideas on how to protect products themselves as we mobilize the product groups across Microsoft. First, I want to mention that we have people across the company that have been reassigned to Product Support, as I mentioned earlier. The engineering teams have been working nonstop on several fronts. The first is to look at improvements to the Internet connection firewall to make sure that we can do the appropriate feature improvement, but also to make sure we can understand cases where turning the Internet connection firewall on caused the application incompatibility. We want to make sure we can reduce those incompatibilities by improving the overall customer experience. The feedback from customers has been, over the last few weeks, is we need to turn the Internet connection firewall on by default. We're currently investigating how to do this, but naturally there are some technical issues and some legal issues we're working through. I want you to know that we're taking this very seriously and are working hard to make sure we can do things like turning on ICF. The second piece of feedback that we've been working on is a better Windows update and auto update experience. Clearly, there are some areas around the user interface, usability that we need to do to make that technology more straightforward. The other feedback we've gotten though has also been the customer wants to turn this on by default. Again, one of the things we've seen is that both for ICF and for the Windows Update, auto update features that the customer desire to have this turned on by default has changed pretty dramatically since we shipped Windows XP about two years ago. Really, the thing we're focusing on right now is making sure we understand that feedback and doing the right thing in a way that's going to provide the maximum level of safety and the minimum level of pain from both the user experience perspective and from a compatibility perspective. The evolution of this really is in three phases. Back before the trustworthy computing initiative, our approach was to turn all features on by default except security features, which tend to get in the way. In phase two, as we began trustworthy computing, really the goal here was to move to turning more features off by default unless they're being used by a large set of customers. In fact, Windows Server 2003 was a great example of that. While secure by default used to mean turning things off, in phase three we're definitely now moving to a phase where we're looking at security features being turned on by default, especially where they're going to help to provide a safer, more secure experience. We realize that in some cases there may be an overall impediment, but the primary goal is to improve the security experience and the safety of our customers using them. To really turn to things we're going to be focusing on improving, first and foremost as part of the trustworthy computing initiative, we're continuing to implement our new release process and focusing on making our product more secure by design, secure by default and secure in deployment. Ultimately, this is how we're going to reduce the number of vulnerabilities. We're also developing more security automation and patch management tools. We've gotten feedback about the need for us to reduce patch complexity. We also have gotten feedback that NBSA and Windows Update sometimes give different answers, and one of the things we're focusing on right now is things we can do to make sure that the patch detection and basic vulnerability analysis of MBSA Windows Update are more consistent and to make sure that the diversion is much lower. One of the things we've also talked about over the last few months is the need for us to have not just a patching mechanism for Windows, but also a patching mechanism for Microsoft products in general. So while we have Windows Update for the Windows desktop and server today, we're looking at building something that you can think of as a Microsoft update. It will provide a similar evolution that provides protection for the full set of Microsoft products, targeting on unmanaged environments. We also have technology called Software Update Services today. Software Update Services provides the same kind of support for Windows desktops and servers in a managed environment, where the IT professional controls what makes these desktops and servers. The feedback we've gotten there is that Software Update Services capability, can be extended for a broader set of Microsoft product, and we're working on that. Lastly, the fact that we have so many patch utilities has caused some complexity for customers, and the key thing we want you to know is that we are working very hard on our patch management strategy to reduce the number of patch utilities down to two. Think of this as one per kernel level changes, one for layered technologies. What's most important here is that by reducing the number of patch utilities, the complexity of verifying patch installations will be greatly reduced, but at the same time, those two patch facilities will be much more consistent, so that even though there are two tools, the experience will be more like there is one. We also realize that we have more work to do to improve the overall secure by design, secure by default and secure in deployment to really, from a secure by design perspective, to do even more work to reduce the number of vulnerabilities in the code. From a secure by default perspective, as I mentioned, not only looking at things that we turn off by default and requiring more appropriate levels of privilege, but also making sure to look at new areas of things we should turn on to make the system more secure by default. Secure in deployment is about having more tools in the form of technology and guidance but also more training, and in particular a lot of work has been done in this space around Blaster. Finally around communications, making sure that we're stepping up the level of both the quality and the depth of the content we're providing to you to ... the information to be more secure, but also - and I want to thank those of you that have given us feedback already and those of you who will be giving us more feedback today - real guidance and input from you, our customers, to make sure we're doing the right thing from a security perspective. As a part of this also - and I mentioned this briefly - we do have a team of people in the company looking at new ways that we can provide a higher level of protection of our system, in some sense to mitigate the need for some of these patches to make sure that even with the patches that are installed, the software is more resilient to exploits. There is a team working on that, and I want to invite you to a call we'll have in a few weeks, where I'll have the opportunity to report back to you both our progress around Blaster in particular, but also get in some more detail and report back to you some of the things we've discovered, some of the areas we'll be investing in to make sure that our system is more secure by default with this added technology. So with that overview, what I'd like to do now is introduce David Treadwell. David, as I said, is the general manager of the .NET Developer Platform team at Microsoft. He is one of our leading technical architects at Microsoft. Among other things, he's responsible for DCOM technology. His team has worked hard both to provide the patch for MS03-026, but also looking at new creative ways that we can provide an even deeper level of protection. So David, let me turn it over to you. David Treadwell ... how they fit in the system, what the technologies do. Secondly, I'd like to tell you about what we're doing with the vulnerabilities we found and the ways in which we're working to make the system more robust against these kinds of vulnerabilities. Third, I'd like to give you guys a bit of an overview on what are the worms, which ones we found and what they do, how they infect your system, technically what's behind them. So let's start off with RPC and DCOM, what they are. RPC stands for Remote Procedure Calls. It's the mechanism that's used to communicate API calls between machines or across processes within a machine. When it runs between machines, it runs over Port 135 typically, and that's why you've seen a lot of communication about us in terms of restricting Port 135 as a mechanism to prevent this at the firewall level. DCOM stands for Distributed COM, it's used as the activation mechanism for RPC servers, among other things. So RPC is the basic infrastructure. DCOM essentially sits on top of it. These technologies are very broadly used in the operating system. They're used both by operating system components as well as applications on top of the operating system. Thus, the fact that there is a vulnerability in the ... components was the reason for the degree of exposure to customers of the issue. Many machines have this code running on them. All of the Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003, have the DCOM and RPC infrastructure in place. MS03-026 is a new class of loop-based buffer overflow. We have some pretty sophisticated tools that we use at Microsoft to catch potential buffer overflows, and we run them diligently. This particular type of buffer overflow is one that the tools didn't previously catch. As I'll tell you in a moment, we've extended our tools to catch this class of problems for the future. Any time something like this goes wrong, we ask ourselves three questions at a high level. First of all, was there a problem with the process? If there is a problem, we fix it. Secondly, was there a problem with education, either of the people on the team or of our customers? If there's a problem there, we fix that. Finally, was there a problem with an individual's performance? If so, of course we fix that as well. That situation is no different. In this particular case, the problem was in process, and we're fixing it. I'll tell you about what we're doing. As soon as the DCOM/RPC vulnerability was reported in early July, we took a number of actions. One of the most significant is that I assembled a team of the very most senior individuals across Microsoft and enlisted them for their support in this problem space. We performed a line-by-line code review, looking carefully at every single bit of code in DCOM and RPC. Literally, these folks were the best talent that Microsoft has to find this problem, which should hopefully show you the level of seriousness with which we're taking this. Next, we improved the source analysis and runtime testing tools. These are the things that help us to practically identify potential issues in the code. We've been applying early releases of these tools to the DCOM and RPC code bases in an effort to see if any other issues along these lines might exist. We've done careful bug scrubs, looking at all the bugs that have been reported on these code bases to see if there is anything else that could have a comparable level of exposure for customers. We've done what we call fuzzing, where we send essentially random data to the machines, to this level of the system to see if there are any other potential kinds of issues that might not be caught by all the other mechanisms I just described. Of course, we have continued to analyze the implementation of secure coding practices. We take our security pushes and other efforts very seriously, and we're looking closely at those to see what we should do there to improve our process and make sure that these problems are minimized. Looking a little bit further, another thing that we've done is we're doing additional reviews by non-Microsoft industry experts. We're applying the best help Microsoft has to it, but we also want to make sure that we apply some of the best help from around the industry to do careful code reviews of this code base, just to get as much diversity as we can in terms of the people looking at the code. We also provide Windows sources to numerous governmental and academic institutions around the world, and of course we're always very interested in their feedback on what we can do better in the code base or if there are any other specific issues in the code. We're additionally increasing our use of third party penetration testing across the products, just as we're doing with DCOM, as I mentioned earlier. Looking forward, we're doing several other things to help customers on their networks. One of the things that Mike mentioned was the scan tool. That was something we did practically to help you find potentially vulnerable machines on your network so that you can take action to address the vulnerability before you became exposed. In the longer term, we're looking at even more significant actions. Mike already described the potential default enabling of ICF and automatic Windows updates. In the DCOM problem space specifically, we're looking at what we call the DCOM firewall to reduce the attack servers for RPC and DCOM interfaces, especially with unauthenticated RPC and DCOM access. We're also looking into reducing the default privilege of the DCOM activation process. So even if there is a problem in the code, the damage that could be caused by an attack is lessened. While we're very focused internally on driving software quality, we deeply appreciate the investments that you customers have made in taking active defensive measures. Your defensive ... work, the strong effort that you made toward patching, both helped yourself and helped the Internet in general by having fewer machines infected. This work will not only improve the defense of your networks, but it will help to improve the global infrastructure as well. We very much appreciate those efforts. As we know, bugs in software are a fact of life. We always work extremely hard to address them as quickly as we can, but the additional measures that you as customers have taken should go a long way toward mitigating the effects of these issues. That was the overview of DCOM and RPC and what we've done about the problem in those areas. Next, I'd like to move onto a technical discussion of the Blaster Worm and give you an idea of what the worm does at a high level and how it can impact you. The Blaster Worm actively attempts to do two things. First of all, it replicates itself to Windows 2000 and Windows XP boxes using the MS03-026 vulnerability. One thing to note is that the Windows 9X code base, Windows 95, Windows 98 and Windows ME, do not have the vulnerable code. So it cannot infect those machines. Secondly, the worm was not written to infect Windows NT 4.0 or Windows Server 2003 machines. It is possible for the worm to cause instability on those machines by taking advantage of the 026 vulnerabilities, but to the best of our knowledge there is not variant to date that actually replicates itself to Windows NT 4.0 or Windows Server 2003 machines. In addition to replicating itself to Windows 2000 and Windows XP boxes, the Blaster Worm has code in it, which is intended to attack the windowsupdate.com URL. It was intended to start attacking it on August 16 and proceed through December 31, and then according to a rather complex algorithm it used internally, to continue other attacks beyond that. One thing to note about this attack is that it was designed to attack the windowsupdate.com URL itself, not the Windows Update infrastructure. Therefore, by taking various actions, Microsoft was able to insure that the Windows Update infrastructure remained up and available for customers to continue getting patches even with the potential of those attacks occurring. We took other actions in terms of removing windowsupdate.com from the DNS infrastructure so that the worm wouldn't incur network traffic on your systems in the effort to do the denial of service attacks it tried on windowsupdate.com. One other thing to note is that windowsupdate.com was a "vanity" URL, which gets redirected to the real location, which is off of Microsoft.com. So removing windowsupdate.com from the DNS infrastructure didn't prevent customers from getting at the information on the Windows Update system from our Web site. Finally, windowsupdate.com was always up. It was never down. The actions that we took insured that it was continuously available to customers to update patches. In the process of the two things that the Blaster Worm tried to do, replicating itself and attacking windowsupdate.com, it does have a number of side effects. One thing that's been broadly reported is the fact that it crashes unpatched Windows NT 4.0, Windows 2000, Windows XP and Windows Server 2003 machines. This is because it tries to take advantage of the vulnerability to replicate itself, but if it doesn't happen to get the right kind of operating system, it will actually cause a crash on an operating system unlike the one it was trying to attack. It also creates a considerable amount of local and Internet network traffic. It does it because of the way it scans for IP addresses that it's looking to attack, by which it uses TFTP to install itself, and also because of all the host unreachable packets that are sent back when it attempts to connect to a non-existent IP address. So how does Blaster replicate? This particular worm only has one replication mechanism. We've seen other worms in the past like NIMDA, which had multiple replication mechanisms, either using different kinds of vulnerabilities or combining specific vulnerabilities with other attacks like social engineering attacks. Blaster only uses the 026 vulnerabilities. What happens is it selects an IP address to attack, and it uses the MS03-026 stack overflow to replicate itself over ... Port 135. Then what happens is it uses the exploit code that was released to the Internet by X-Focus on July 25 to create a shelf server on the victim machine. The shelf server makes itself available on Port 4444, listening to somebody to give it a shelf command to execute. The attacker then opens Port 69 on itself as a TFTP machine and instructs the victim to download the file msblast.exe from this rudimentary TFTP server. The victim then executes msblast.exe, and it is then infected and begins to attack other machines using that algorithm. So that's the basic Blaster Worm. We've also received a lot of information about a variety of variants that have appeared in the last week, as well as new information about a lot of old viruses and old virus attack mechanisms. I want to review a few of these with you, but specifically encourage you to talk to your antivirus vendors, especially looking at their Web sites, to get more specific details on these issues. Of course, every time we hear about a new worm, our engineers work very closely with the security community to understand what the worm does, to see the threat that it poses, to determine whether it's a new vulnerability and to see what mitigations are effective against it. To the best of our knowledge at this point in time, the guidance that we have given customers thus far about installing the patch, enabling the Internet connection firewall and disabling certain ports of Internet firewalls is good protection against all of the worms. We don't know any worms that take advantage of other issues beyond the ones that we've described how to fix in our guidance. There are several variations of Blaster, also known as Love Send, because of the string text that's encoded in it. Again, these all use MS03-026 to spread and attack windowsupdate.com. Protection is to use Internet connection firewall, use Internet firewalls and to have up to date patches. If you have 026 on your machine, it's not possible to be infected by these particular worms. There was also sometimes called patching worms like Nachi/Welchia. These exploit MS03-026 as well as another older vulnerability, MS03-007, and they attempt to install a security patch, the 026 and 007 security patches. But in the course of doing this, they also cause considerable network trafficking congestion as they're searching for machines to patch. They can also have certain system instabilities because if you don't get just the right operating system that they're trying to patch, they might cause some of the RPCSS processes to crash. Another class of worms that we've heard about and investigated is what we call RPCSDBOT. These are backdoors that essentially use the same replication mechanisms as Blaster and are very related to Blaster in the code that they execute, but they do one additional thing. They install a backdoor that listens to an IRC server, an Internet Relay Chat server, where they can receive commands and therefore be directed to attack other specific machines. Again, the same guidance that we've given on protecting yourself from Blaster will protect you from these worms. Install the patch, run ICF, run other firewalls. Recently, there has also been a number of reports and a number of people infected by what's been called the SoBig worm. This is not related to 026 in the sense it doesn't take advantage of that vulnerability. Rather, it's what we call a social engineering worm. A social engineering worm is one where you induce a user to run a program. That program is, of course, the virus and then it takes whatever action it wants to on the user's machine. The SoBig worm uses e-mail and network shares as its social engineering propagation mechanism. The protections against SoBig are firewalls using antivirus software from your antivirus vendor and especially the Outlook e-mail patch protection. This has been available for releases of Outlook since Outlook 97 and makes it much more difficult for the social engineering attack to work. Finally, there have been a number of fake e-mails claiming to come from Microsoft Support sent to a number of people who are on the Internet. These fake e-mails typically include an attachment, which could have any number of viruses in them. It's another form of social engineering attack not directly related to 026, but which has affected a number of people. The same protection mechanisms apply here as it applied to the SoBig worm - firewalls, antivirus and the Outlook e-mail patch. With that, I'd like to hand it back to Mike to talk to you about some of the actions that you can take, if you haven't done so already, to protect your business and your customers. Mike Nash Thanks, David. By this point, I hope that a lot of this guidance is information that you've already seen. I want to go through it again just to make sure that you have an opportunity to both hear it directly from Microsoft, but at the same time also have the opportunity to give us feedback about it and tell us anything that we can do to make things even more clear. I also want to be clear that this guide for businesses is equally important for consumers as well, because first of all, we know that a lot of the desktop systems are on the same network, the Internet, and in many cases those home consumer systems are connecting into your network, and I want to make sure that you've got a deep understanding of some of the risks and concerns we've got to provide there as well. The first and foremost bit of information here is: verify your firewall configuration. I know that most enterprise customers, therefore most customers that are on this call, have firewalls in place. The key thing we've heard from several customers has been that sometimes those firewalls are not configured in a way that is appropriate. Our guidance here is that you block all ports that are not required by your applications. For example here, we recommend that you block Port 135 at the edge unless you have some application that's requiring that across the edge of your network. We also recommend that you evaluate using host-level firewalls on your client systems. One example here is the Internet Connection Firewall built into Windows XP. I think the key thing to realize here is that especially for remote systems - either laptops or home machines that are VPN'ing into your corporate network - in some sense these systems represent a new edge of your network. Therefore, it's important that you have the same level of protection on those systems as you have on your edge itself. I do want to note very clearly that ICF is effective at protecting even unpatched systems from the Blaster Worm. Therefore, it's very important to use that as a tool to protect the edge of your network. We also want to make you aware of some solution guides we've created; some prior to the first instance of Blaster and some that we've been doing in response. Up on Microsoft.com/technet/security, there are some great solution guides, in particular focusing on patch management, on securing Windows XP Professional, on securing Windows 2000 and on securing Windows Server 2003. We also have security solution guides around wireless and identity management. The third point - and I know this is something that has caused quite a bit of pain - but we have worked to make sure it's easier for you to know about security updates, in particular having security notification systems that you can find, that you can subscribe to rather, by going to www.Microsoft.com/securitynotification, all those two words squashed together. There's information there that describes both the consumer version of this goal of the service, which focuses on consumer products using consumer language, but also a technical version that provides a -- a technical version of the service rather -- that provides technical versions of the bulletins as well as more technical depth on the individual vulnerabilities and the patches themselves. Microsoft has also created a technology called Software Update Services that I mentioned briefly earlier, sometimes called SUS. Software Update Services are really designed to help make sure that in a management environment you have the ability to control the patches going into Windows desktops and servers in your environment. In a similar service also for end user machines or machines in an unmanaged environment called Windows Update, which provides the same level of functionality, but has a configuration that automatically allows for the installation of Windows patches on Windows desktops and servers, and in particular, it can be configured to automatically download, check for automatically download and install patches at a prescribed time each day. Microsoft also has a product called Systems Management Server, also called SMS. There's actually a new version of this thing coming out shortly, which is very much designed to make it easier to deploy patches. I know that staying on the patch process is a very cumbersome process for you, which is why we're looking at new mitigation approaches to take some of the pressure off, but I do want to make you aware of some of the things we're doing to make it easier for you to manage the patching process. Thirdly, is the need to use the antivirus software. I know that for most enterprise accounts, certainly for a lot of the folks on the call here today, it's not news to you that you need to install antivirus products. It is important though that you go back and verify those systems that the software actually contains to be installed on your client in certain machines in your environment, that those machines are being scanned regularly, and those machines are taking the latest signatures. It's very important that you keep antivirus up to date and especially for portable machines and machines that are coming in, personal machines perhaps VPN'ing into your network, that you make sure those machines have antivirus software installed and the antivirus software is up to date before you allow those systems onto your corporate network. We especially recommend this for machines that are redefining the edge of your machine either as a VPN laptop or a VPN remote machine. We also recommend you look at new ways, new places in your network to do antivirus scanning, whether that's e-mail servers or antivirus at the edge, all areas that you may want to look at. I also want to emphasize finally in terms of the guidance here is that you further protect your network by requiring employees to take the same level of these three steps on home machines, because it's those machines, in some cases we've heard reports of those home machines causing the infections into otherwise protected networks. I think pragmatically we have to realize those machines are going to get on the network, and therefore, we have to give our employees the tools they need to keep their systems safe and secure. Before we go to the Q&A, I do want to set expectations about what you can expect from Microsoft. Certainly, and as I mentioned earlier, this event only highlights and reinforces our commitment to the Trustworthy Computing Initiative and the TWC release processes around security. We're continuing to make our investments around improving the security process and creating new tools to make it easier for you to both automate and streamline the patch management process. We've also done a significant amount of work to elevate our level of focus on innovative software protection tools. David mentioned the DCOM firewall, but really the idea here is to make sure we have new technology to protect your systems even when our systems are unpatched. I do want to, again, commit to you that I will schedule another conference call like this in the coming weeks, so we can update you on the progress around Blaster, but also to give you an update on some of the work we've looked at with our senior engineering staff to improve the overall security and resilience of Windows systems. © 2003 Microsoft Corporation. All rights reserved. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. Microsoft is a registered trademark of Microsoft Corporation in the United States and/or other countries. References 1. file://localhost/tmp/\l 2. file://localhost/tmp/\l 3. file://localhost/tmp/\l 4. file://localhost/tmp/\l 5. file://localhost/tmp/\l 6. file://localhost/tmp/\l 7. file://localhost/tmp/\l 8. file://localhost/tmp/\l 9. file://localhost/tmp/\l 10. file://localhost/tmp/\l