本帖最后由 zdshsls 于 2011-6-28 10:32 编辑
德文EMET文章
Es ist l?ngst kein Geheimnis mehr, dass die meisten Malware-Infektionen durch den Missbrauch von Bugs in Anwendungen – und nicht l?nger dem Betriebssystem – von statten gehen. Wer also die Schwachstellen in seinen Applikationen minimiert, verringert die Angriffsfl?che – was wiederum leichter klingt, als es de facto umzusetzen ist. Unser monatlicher Patch-Tag ist der beste Beweis hierfür :)
Aber es gibt auch einige Tools, die Entwicklern beim Abwehren g?ngiger Attacken helfen k?nnen. Eines dieser Hilfsmittel ist das Enhanced Mitigation Experience Toolkit V 2.0 (EMET) von Microsoft. Das kostenlose Programm ist für alle Windows-Programme gedacht und ben?tigt, anders als andere Tools, keinen Zugriff auf den Sourcecode - die ausführbare Datei genügt.
EMET kann insgesamt sieben zus?tzliche Sicherheitstechniken auf Applikationen anwenden - selbst, wenn Entwickler diese gar nicht vorgesehen haben. Dazu geh?ren beispielsweise die Unterstützung für Data Executive Prevention (DEP), Structured Exception Handling Overwrite Protection (SEHOP) oder NullPage. SEHOP überprüft beispielsweise den Programmablauf. Sobald eine Ablaufkette ein Problem aufzeigt, wird der Prozess beendet - so wird verhindert, dass sich ein b?sartiges Programm den Fehler zu Nutze macht, um unerlaubt auf einen Speicherbereich zugreifen zu k?nnen. DEP ist seit Windows XP Bestandteil von Windows, Programme müssen aber mit einem speziellen Flag kompiliert werden - EMET kann den Prozess auch ohne dieses Flag schützen.
Nach der Installation l?sst sich EMET wahlweise über die GUI oder die Kommandozeile starten. Zu überwachende Anwendungen werden über die Schaltfl?che ?Configure Apps“ hinzugefügt. Zudem l?sst sich hier w?hlen, welche Techniken EMET auf das jeweilige Programm anwenden soll.
Warum sind die vom EMET geprüften Sicherheitsfunktionen nicht standardm??ig aktiv und Teil des Sourcecodes? Einige der Funktionen verursachen unter Umst?nden Probleme. Zudem bedeutet die Funktion nicht automatisch, dass die jeweilige Anwendung komplett gegen Attacken geschützt wird. Allerdings wird es deutlich schwerer, Schwachstellen in installierten Programmen auszunutzen, um Malware zu installieren. Dieser Blog-Eintrag erkl?rt beispielsweise, wie sich eine Zero-Day-Attacke auf Adobe Acrobat Reader mit Hilfe von EMET verhindern l?sst. Adobe setzt zwar normalerweise auf Address Space Layout Randomization (ASLR), für eine spezielle DLL ist dieser Schutz aber nicht aktiviert - EMET rüstet die Funktion nach und schützt so vor dem Angriff.
Google翻译
这不是什么秘密,从应用程序中的漏洞最多人滥用的恶意软件感染 - 去交 - 不再操作系统。 因此,如果您最大限度地减少其应用的漏洞,减少了攻击面 - 这听起来容易,从而比它实际上是在执行。 我们的月度补丁日是最好的证据是:)
但也有一些工具,开发人员可以击退攻击是常见的。 一个这样的工具是 加强缓解体验工具包2.0版(EMET) 从Microsoft。 免费的方案是专为所有的Windows程序和需要,不像其他工具无法访问源代码-可执行文件就足够了。
EMET可以申请另外七个应用程序的安全技术 - 即使这些开发商都没有提供。 例子包括数据执行保护(DEP),结构化异常处理覆盖保护(SEHOP)或零页的支持。 SEHOP审查,例如,程序流。 一旦一个序列呈现出,在此过程完成的问题 - 这将防止恶意程序利用的错误,以便利用非法访问一个存储区域可以。 自Windows XP的DEP的Windows的一部分编制,方案的需要,但有一个特殊的标志 - EMET可以保护,即使没有这个标志的进程。
安装完毕后,可以开始EMET要么与GUI或命令行。 要控制应用程序可以通过添加“配置应用程序。 也可以选择在这里,技术EMET应适用于特定的程序。
为什么是EMET考验的安全功能无法启用默认源代码和部分? 一些职能的也会造成问题。 此外,该函数并不自动意味着该应用程序是完全免受攻击。 但是,它更难以利用的方案漏洞安装到安装恶意软件。 这个博客条目 解释,例如如何通过使用Acrobat Reader零日攻击,使Adobe防止EMET。 土坯一般必将地址空间布局随机化(ASLR),一个特殊的DLL的保护没有被激活-EMET升级到攻击保护功能和反对。
=====================================================
EMET英文用户指南,由“一晴空”会员翻译,51L
EMET 2.1
1.说明
EMET工具包被设计用于防止黑客进入你的系统,软件的易受攻击和漏洞已经成为日常生活的一部分,几乎每个厂商都会对付它们(漏洞),因此,用户面临一连串的安全更新,用户在得到最新更新之前受到攻击或者甚至在一个可用更新发布之前受到攻击,结果将是灾难性的:恶意软件,有价证券等。安全减灾技术都是为了增大攻击者在一个特定软件中利用漏洞来攻击的难度.EMET允许用户管理这些技术,在他们的系统上提供几个独特的好处(微软真谦虚,呵呵)。
1.没有任何源代码(?啥意思)直到现在,几个可用的减缓隐患的方法(如DEP)要求一个应用程序由人工选择和重新编译.EMET改变了这种方式,通过允许用户改变对应用软件的选择而无需重新编译.这是特别有用的部署(在写软件有隐患前和当源代码不可用时。)
2.高度可配置性
EMET提供更高的等级通过允许(隐患)粒度要单独应用每一个过程的基础。没有必要使整个产品或组的应用。在这种情况下,这是有用的过程(不兼容一个特定的缓解技术)。当这种情况出现时,用户可以简单地转换以缓解这个过程。
3.帮助增强legacy程序:这是典型的硬软件依赖老技术而不易改写现象,需要被逐渐淘汰。不幸的是,这种可以很容易地构成安全威胁作为legacy软件是臭名昭著的有安全漏洞。而真正解决的办法就是远离legacy软件,EMET能帮助管理风险(当风险发生时),使黑客在攻击legacy软件漏洞(弱点)时的难度加大.
4.简单易用:策略(隐患)系统范围与EMET可看的和配置的图形用户界面。有不需要定位和解读的注册表项或平台相关工具。在EMET的引导下你可以调整设置不管一个一致的接口与潜在的平台。
5.持续改进:EMET是一个灵活的工具,设计更新使新缓解技术变得可用。这为用户提供了一个机会来测试和受益于排除隐患。EMET也不拘泥于任何产品。可动态更新令EMET一旦发现新的(隐患),这个工具包包括几个伪缓解的技术目标(使用当前利用技术)。打乱这些不具有较强的隐患,不停止的未来开发技术,但是可以帮助用户受到危害的许多情况使用。也为了使他们可以很容易地更新产品,为攻击者设计(防御)使用新开发的技术。
Microsoft Corporation
Enhanced Mitigation Experience Toolkit 2.1
1. Introduction
The enhanced Mitigation Experience Toolkit (EMET) is designed to
help prevent hackers from gaining access to your system.
Software vulnerabilities and exploits have become an everyday
part of life. Virtually every product has to deal with them and
consequently, users are faced with a stream of security updates.
For users who get attacked before the latest updates have been
applied or who get attacked before an update is even available,
the results can be devastating: malware, loss of PII, etc.
Security mitigation technologies are designed to make it more
difficult for an attacker to exploit vulnerabilities in a given
piece of software. EMET allows users to manage these technologies
on their system and provides several unique benefits:
1. No source code needed: Until now, several of the available
mitigations (such as Data Execution Prevention) have required for
an application to be manually opted in and recompiled. EMET
changes this by allowing a user to opt in applications without
recompilation. This is especially handy for deploying mitigations
on software that was written before the mitigations were
available and when source code is not available.
2. Highly configurable: EMET provides a higher degree of
granularity by allowing mitigations to be individually applied on
a per process basis. There is no need to enable an entire product
or suite of applications. This is helpful in situations where a
process is not compatible with a particular mitigation
technology. When that happens, a user can simply turn that
mitigation off for that process.
3. Helps harden legacy applications: It’s not uncommon to have a
hard dependency on old legacy software that cannot easily be
rewritten and needs to be phased out slowly. Unfortunately, this
can easily pose a security risk as legacy software is notorious
for having security vulnerabilities. While the real solution to
this is migrating away from the legacy software, EMET can help
manage the risk while this is occurring by making it harder to
hackers to exploit vulnerabilities in the legacy software.
4. Ease of use: The policy for system wide mitigations can be
seen and configured with EMET's graphical user interface. There
is no need to locate up and decipher registry keys or run
platform dependent utilities. With EMET you can adjust setting
with a single consistent interface regardless of the underlying
platform.
5. Ongoing improvement: EMET is a living tool designed to be
updated as new mitigation technologies become available. This
provides a chance for users to try out and benefit from cutting
edge mitigations. The release cycle for EMET is also not tied to
any product. EMET updates can be made dynamically as soon as new
mitigations are ready
The toolkit includes several pseudo mitigation technologies aimed
at disrupting current exploit techniques. These pseudo
mitigations are not robust enough to stop future exploit
techniques, but can help prevent users from being compromised by
many of the exploits currently in use. The mitigations are also
designed so that they can be easily updated as attackers start
using new exploit techniques.
1.1. Capabilities
EMET 2.1 allows users to both configure the system policy for
mitigations as well as to configure mitigations on a per
executable basis. The first option allows the user to set the
defaults for system supported mitigaitons; for instance choosing
whether one should be enabled for all processes, enabled for only
those that chose to opt in, disabled entirely etc. The second
option allows the user to enable an EMET supported mitigation on
an arbitrary executable. Any one of the supported mitigations can
idependently be turned on and off for any executable residing on
the system. Next time one of the configured executables runs, the
specified mitigations will be applied to it. Combining these two
options gives the user a high degree of control over the
mitigations available on a system and how they get used.
NOTE: Before continuing, please be aware that some security
mitigation technologies may break applications. It is important
to thoroughly test EMET in all target use scenarios before
rolling it out to a production environment.
1.2. Supported mitigations
The current version supports six different mitigation
technologies. A training video covering many of the mitigations
is available here: http://technet.microsoft.com/en-
us/security/ff859539.aspx. The remainder of this section will
outline the different mitigations and the protections they
provide.
Structure Exception Handler Overwrite Protection (SEHOP)
This protects against currently the most common technique for
exploiting stack overflows in Windows. This mitigation has
shipped with Windows since Windows Vista SP1. Recently with
Windows 7, the ability to turn it on and off per process was
added. With EMET, we provide the Windows 7 capabilities on any
platform back though Windows XP. For more information, take a
look at the SEHOP Overview and Window 7 SEHOP Changes blog posts.
Without EMET in place an attacker can overwrite, with a
controlled value, the handler pointer of an exception record on
the stack. Once an exception happens, the OS will walk the
exception record chain and call all the handler on each exception
record. Since the attacker controls one of the records, the OS
will jump to wherever the attacker wants, giving the attacker
control the flow of execution. See figure 1 for an illustration
of this.
Figure 1: An exception handler hijack
With EMET in place, before the OS calls any exception handlers,
it will validate the exception record chain. This involves
checking if the final exception contains a predefined one. If the
chain is corrupted, EMET will terminate the process without
calling any of the handlers. Figure 2 illustrates what this looks
like.
Figure 2: EMET stopping an exception handler hijack
Dynamice Data Execution Prevention (DEP)
DEP has been available since Windows XP. However, current
configuration options don’t allow applications to be opted in on
an individual basis unless they are compiled with a special flag.
EMET allows applications compiled without that flag to also be
opted. For more information on what DEP is and how it works, take
a look at Part 1 and Part 2 of our two-part SRD blog post on it.
Without EMET in place, an attacker can attempt to exploit a
vulnerability by jumping to shellcode at a memory location where
attacker controlled data resides such as the heap or stack. Since
these regions are marked as executable the malicious code will be
able to run.
Figure 3: Running shellcode from attacker controlled locations
Turning EMET on will enable DEP for a process. Once this happens,
the stack and heap will be marked as non-executable and any
attempt to execute malicious code from these regions will be
denied at the processor level.
Figure 4: DEP blocking shellcode from running
Heapspray Allocations
When an exploit runs, it often cannot be sure of the address
where its shellcode resides and must guess when taking control of
the instruction pointer. To increase the odds of success, most
exploits now use heapspray techniques to place copies of their
shellcode at as many memory locations as possible. Figure 5 shows
an illustration of what this looks like in a victim process.
Figure 5: Using heapspray in an exploit
With EMET in place some commonly used pages are pre-allocated.
Exploits that rely on controlling these pages (and then jumping
into them) will fail.
Figure 6: Blocking an attack that uses heapspray
Please note this is a pseudo mitigation designed to break current
exploit techniques. It is not designed to break future exploits
as well. As exploit techniques continue to evolve, so will EMET.
Null page allocation
This is similar technology to the heap spray allocation, but
designed to prevent potential null dereference issues in user
mode. Currently there are no known ways to exploit them and thus
this is a defense in depth mitigation technology.
Mandatory Address Space Layout Randomization (ASLR)
ASLR randomizes the addresses where modules are loaded to help
prevent an attacker from leveraging data at predictable
locations. The problem with this is that all modules have to use
a compile time flag to opt into this.
Without EMET in place, attackers can take advantage of a
predictable mapping of those dlls and could use them in order to
bypass DEP though a known technique called return oriented
programming (ROP).
Figure 7: A module being loaded at a predictable location
With EMET in place, we force modules to be loaded at randomized
addresses for a target process regardless of the flags it was
compiled with. Exploits using ROP and relying on predictable
mappings will fail.
Figure 8: A module being forced to load at a random address
Export Address Table Access Filtering (EAF)
In order to do something “useful”, shellcode generally needs to
call Windows APIs. However, in order to call an API, shellcode
must first find the address where that API has been loaded. To do
this the vast majority of shellcode iterates through the export
address table of all loaded modules, looking for modules that
contain useful APIs. Typically this involves kernel32.dll or
ntdll.dll. Once an interesting module has been found, the
shellcode can then figure out the address where an API in that
module resides.
This mitigation filters accesses to the Export Address Table
(EAT), allowing or disallowing the read/write access based on the
calling code. With EMET in place, most of today’s shellcode will
be blocked when it tries to lookup the APIs needed for its
payload.
Please note this is a pseudo mitigation designed to break current
exploit techniques. It is not designed to break future exploits
as well. As exploit techniques continue to evolve, so will EMET.
Bottom-up randomization
This mitigation randomizes (8 bits of entropy) the base address
of bottom-up allocations (including heaps, stacks, and other
memory allocations) once EMET has enabled this mitigation but not
for previous allocations.
1.3. Supported operating systems
EMET 2.1 supports the following operating systems and service
pack levels:
Client Operating Systems
Windows XP service pack 3 and above
Windows Vista service pack 1 and above
Windows 7 all service packs
Server Operation Systems
Windows Server 2003 service pack 1 and above
Windows Server 2008 all service packs
Windows Server 2008 R2 all service packs
Please note that not all mitigations are supported on each
operating system. . Mitigation XP Server 2003 Vista Server 2008
Win7 Server 2008 R2
System Settings
Additionally, on 64 bit systems, some application specific
mitigations are only applicable when running on 32 bit processes.
For details, refer to the following table. Mitigation 32 bit
Processes 64 bit Processes
Application Settings
DEP
Supported by EMET
Already Mandatory without EMET
SEHOP
Supported by EMET
Not Applicable
NULL Page
Supported by EMET
Supported by EMET
Heap Spray
Supported by EMET
Supported by EMET
Mandatory ASLR
Supported by EMET
Supported by EMET
EAF
Supported by EMET
Supported by EMET
Bottom-up
Supported by EMET
Supported by EMET
2. The graphical user interface
The preferred method of interacting with EMET it through the
graphical user interface (GUI). You can launch this program
through the start menu icon crating during the EMET installation.
In this section we will walk you through the various windows of
this interface.
2.1. The main window
When EMET is launched the following GUI is be presented to the
user.
Though this initial window a user will be able to display the
status of the different system mitigations and whether or not any
of the running processes have been opted-in to EMET. Please note
the list of running processes is only updated every 30 seconds.
To get updated information on demand, click the button next to
“Running Processes”.
A user can also click on either of the two buttons to configure
system mitiations or to opt-in an application to the EMET
supported mitigations.
Refresh the list of running processes
Configure system mitigations
Configure application specific mitigations
2.2. Configuring system mitigations
Users can configure system wide mitigations in two different
ways. Either they can select one of the two profiles (“Maximum
Security Settings” and “Recommended Security Settings”) or set
the mitigation configuration individually.
Please note some configuration changes will require rebooting the
operating system. EMET’s GUI provides notification of this when
it happens.
2.3. Configuring mitigations for applications
Users will be able to configure specific applications to opt-in
to the mitigations supported by EMET. Additionally, mitigations
can be individually enabled or disabled on a per application
basis.
For instance, a user will be able configure iexplore.exe to opt-
in to all EMET’s mitigation and, at the same time, opt-in
firefox.exe only for SEHOP and Mandatory ASLR.
Users will be able to Add and Remove applications from the list
by clicking the corresponding buttons. When adding an
application, a user will get prompted with the regular open file
dialog and once having selected one it will get added to this
list. Then, user will be able to configure it.
It is important to note that the opt-in list is path dependent. A
user must opt in the full path for each executable to be
configured with EMET. Placing the mouse over an executable name
will cause a tooltip to appear, showing the full path to the
executable.
EMET will only be in place with the selected configuration after
you click the Ok button and after you restart the newly
added/configured application(s).
|