Microsoft Baseline Security Analyzer exploit (Exposed vulnerabilities' list)
Date: Thu, 25 Apr 2002 03:06:32 +0200
From: Menashe Eliezer <menashe@finjan.com>
To: Bugtraq <bugtraq@securityfocus.com>, vuln-dev <vuln-dev@securityfocus.com>
Subject: Microsoft Baseline Security Analyzer exploit (Exposed vulnerabilities' list)
------=_NextPart_000_004A_01C1EC06.337159B0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Microsoft Baseline Security Analyzer exploit (Exposed vulnerabilities' list)
Finjan Software Security Advisory
URL: http://www.finjan.com/mcrc/alert_show.cfm?attack_release_id=71
April 24, 2002
Risk: Medium
-------------
OVERVIEW
Microsoft released Baseline Security Analyzer on April 8, 2002. The
Microsoft Baseline Security Analyzer (MBSA) analyzes Windows systems for
common security misconfigurations. 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
Microsoft Baseline Security Analyzer (MBSA) is a good security tool.
However, as a security company, we feel that there is a security risk. 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. Any active content object can read
this information. (Executables, scripts, ActiveX, Java) Even if this report
can be accessed only by a specific user, the active content can access it
too. 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 haven't 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.
TECHNICAL OVERVIEW
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 isn't the option of the automatic attack, even though new
exploits are published quite often. Users often don't 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 don't believe that IE should be changed. Active content risks are
known (and can be handled by Finjan's behavior-inspection applications).
Mitigating factors:
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 won't be automatic on fully patched machines
with default security settings selected. However, many machines are not so
"resistant".
Vulnerable Software:
Microsoft Baseline Security Analyzer (MBSA) 1.0 .
How Microsoft can improve MBSA:
Taking care of at least one of the following problems will make it more
difficult for active content to exploit MBSA reports:
1. Let the user change the default location.
2. Encode the report and protect it with a password. Upon opening the file,
a user will be asked for a password in order to decode the file.
3. Recommend that the user remove the report when it's no longer needed.
PROTECTION
1) Deploy proactive security solutions to defend against new and unknown
attacks. (See Finjan's alert for details)
2) Practice safe computing: Install security patches issued by your software
vendors, and make sure that security settings are properly defined. Please
note that user still has the option to trust the active content. Follow MBSA
recommendations, and this list will be empty...
3) Move the created "SecurityScans" folder to unpredicted location, and use
Internet Explorer to read it. Remove the created report when it's no longer
needed.
MICROSOFT RESPONSE
Finjan Malicious Code Research Center had an interesting discussion with
Microsoft Security Response Center.
Their response is attached.
--
Regards,
Menashe Eliezer
Manager, Malicious Code Research Center
Finjan Software - Proactive defense against malicious active content
Web: http://www.finjan.com/
------=_NextPart_000_004A_01C1EC06.337159B0
Content-Type: text/plain;
name="Microsoft Response to MBSA security advisory.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Microsoft Response to MBSA security advisory.txt"
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 it's 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's true that MBSA stores its information in a known
location, storing it in an unpredictable location wouldn't measurably
change the situation. An attacker's code could just as easily search
the local system for the file. Likewise, it's true that MBSA's
information can be read by the user (or code running as the user). But
even if the MBSA information weren't 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's 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 can't run code, it doesn't matter
how the MBSA data is stored, because the attacker can't access it. If
the attacker can run code, he or she doesn't 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 are looking at these
suggestions along with others that we've received and consider them as
they design future versions of this tool.
Thanks again for sending this on, we really appreciate it.
Regards,
secure@microsoft.com
------=_NextPart_000_004A_01C1EC06.337159B0--
