Microsoft Baseline Security Analyzer exploit (Exposed vulnerabilities' list)
26 Apr. 2002
After MBSA analyzes the system for security vulnerabilities, a report is created as a plain text file that includes sensitive information that can be used by hackers to attack the specific machine. MBSA was created to help users become aware of risks and available patches. However, MBSA turns the simple vulnerability of reading local files into a much more powerful vulnerability. Such a simple vulnerability allows potential hackers to find out about vulnerabilities that enable full control over the machine that is under attack. These are automatic attacks.
This means that active content (executables, scripts, ActiveX, Java, etc.) has the ability to generate a list of vulnerabilities or read a previously created list, and can then utilize these vulnerabilities to its advantage. Even if this report can be accessed only by a specific user, the active content can access it too.
Microsoft Baseline Security Analyzer (MBSA) 1.0
If the report is located in an NTFS partition, only the user can access it. However, any active content is launched with user permissions and can read this information. Such attack will not be automatic on fully patched machines with default security settings selected. However, many machines are not so "resistant".
Microsoft released Baseline Security Analyzer on April 8, 2002. The Microsoft Baseline Security Analyzer (MBSA) analyzes Windows systems for common security mis-configurations. Version 1.0 of MBSA includes a graphical and command line interface that can perform local or remote scans of Windows systems. MBSA runs on Windows 2000 and Windows XP systems and will scan for missing Hotfixes and vulnerabilities in main Microsoft's products. More information can be found at: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/Tools/mbsahome.asp
MBSA creates a report that includes sensitive information that can be used by hackers and save them research time. The report can be accessed by a malicious active content:
1. The report is written to a known folder, e.g., C:\Documents and Settings\username\SecurityScans. The user cannot change this location.
2. The XML report is written in plain text and can be used by hackers to find the machine's vulnerabilities.
The problem is not the option of the automatic attack, even though new exploits are published quite often. Users often do not follow Microsoft's advice regarding security patches and security settings. Even a user with a fully patched version of IE may choose to trust certain active content and launch it.
It is very easy to write malicious active content that will access the MBSA report. We do not believe that IE should be changed. Active content risks are known (and can be handled by Finjan's behavior-inspection applications).
Ways of delivery:
There are many ways to deliver such active content. For example:
1. Embedded in a web page and utilizing low security settings for the browser, or on the user's acceptance of the object.
2. Embedded in a HTML-formatted e-mail
3. E-mail attachments.
4. Executable downloads.
Examples of active content that access the file system can be found at: http://www.finjan.com/mcrc/sec_test.cfm (If you are using one of Finjan's behavior-based security products, please disable it before running these demos)
Some attacks will be automatic if the browser's security setting is low, for example, the Java, and the ActiveX demos at the above test site. Based on our disclosure policy, we have not written a specific demo for demonstrating this risk, but it would be quite simple to do so.
We had an interesting discussion with Microsoft about this exploit, and their response is quoted in the bottom of this alert.
Finjan Software warns that this exploit may be used in the wild, and strongly advises you to take proper precautions to protect yourself from this type of attack. Finjan products block this exploit by offering the only solution that proactively inspects active content behavior both in gateway and in desktop level. (Based on two different patented technologies)
Finjan Malicious Code Research Center had an interesting discussion with Microsoft Security Response Center. This is their response:
Hi, Thanks very much for your note and for sending this on. We really appreciate it. To understand the issue fully, it would be good to expand this somewhat. There really are two issues here: One related to the ability to mount an attack successfully, and one related to how data is stored on a system and what could happen to that in light of a successful attack. To be clear, none of the attack scenarios that you've described are mounted through MBSA itself. Also, the attack you've described does not exploit a vulnerability in any product: in a default system this attack fails. It's only when a user chooses to run code from an untrusted source and proceed despite the security warnings provided that this attack could succeed. Protecting systems against untrusted code is vitally important, and we call this out in our 10 Immutable Laws of Security as Law #1 ( http://www.microsoft.com/technet/columns/security/10imlaws.asp ), to underscore its importance. If an attacker were able to convince a user to run their code, that code would then be able to take any actions on the system that the user can take. While it is true that MBSA stores its information in a known location, storing it in an unpredictable location would not measurably change the situation. An attacker's code could just as easily search the local system for the file. Likewise, it is true that MBSA's information can be read by the user (or code running as the user). However, even if the MBSA information were not present on the system, code running as the user would be able to determine the presence or absence of patches, simply by consulting the time/date information contained in the publicly available MSSecure XML database. Again, it is a question of degree rather than feasibility. The larger issue in both cases is the presence of code running with the user's privileges. If the attacker cannot run code, it does not matter how the MBSA data is stored, because the attacker cannot access it. If the attacker can run code, he or she does not need the MBSA data, as they already have all the privileges needed to duplicate the MBSA processing. (For that matter, the attacker could simply run MBSA itself and do a "screen scrape"). That said, we are always looking to make improvements and we appreciate concerns and feedback like this. Our MBSA team is looking at these suggestions along with others that we have received and consider them as they design future versions of this tool.
Thanks again for sending this on, we really appreciate it.