Bypassing SRP and AppLocker For Fun
One of the main things that lets down information security policies and practices is been weakening improved security in order to allow for greater ease of use. Whether it is something as straight forward as manually chocking open an access controlled door because finding the right access token becomes too onerous, or something less obvious like tying a secure single sign on process to a relatively insecure system logon, the weakening of security for usability can take many forms.
Improving the quality and security of software being written by developers means not only training them correctly, but also providing them with the tools that make it simpler to write secure code. One of the concepts available for developers writing for the Windows platform is Software Restriction Policies (SRP) and AppLocker, tools that allow administrators to centrally manage what software a system is allowed to run. In theory, these tools help keep systems secure as they should prevent unauthorised code from running, stopping malware from taking hold as it won't meet the criteria for being able to run under a tight SRP or AppLocker ruleset.
Recent research by Belgian Information Security researcher, Didier Stevens, has uncovered ways by which any restriction put in place by SRP or AppLocker can be bypassed to run arbitrary code.
From the research presented, it appears that the means to bypass SRP and AppLocker protection is a result of intentional weakening from within. The API calls that can be used to executed code at will are even acknowledged in the MSDN documentation as having that feature. In the examples given, an Excel file is, using macros (which aren't checked against SRP or AppLocker), able to create and run code of choice. The initial announcement highlighted that the procedure could only load arbitrary code into an existing, approved and running process. It would not allow a completely new application / process to be launched.
Subsequently, a method was found where it is possible to launch a process that isn't whitelisted, expanding the opportunity for mischief and a severely neutered SRP / AppLocker concept. There is still the problem of getting the initial code to be called, but there are any number of existing methods that allow this through rather simple means.
26 January 2011
Social bookmark this page at eKstreme.
Alternatively, Bookmark or Share via AddThis
Do you like how we cover Information Security news? How about checking out our company services, delivered the same way our news is.
Let our Free OS X Screen Saver deliver the latest security alerts and commentary to your desktop when you're not at your system.
Comments will soon be available for registered users.
Subscribe to our feed.