1 / 17

Privilege Escalation

Privilege Escalation. Two case studies. Privilege Escalation. To better understand how privilege escalation can work, we will look at two relatively recent examples . Both cases impacted all recent versions of the Windows family of operating systems. Case 1.

xantha-mccarthy
Download Presentation

Privilege Escalation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Privilege Escalation Two case studies

  2. Privilege Escalation • To better understand how privilege escalation can work, we will look at two relatively recent examples. • Both cases impacted all recent versions of the Windows family of operating systems.

  3. Case 1 • The first case is the Windows Task Scheduler vulnerability. • This exploit affected all versions of Windows from Vista onwards. • Includes the server operating systems. • A real zero day exploit.

  4. Task Scheduler • The exploit takes advantage of the changes made to the Windows task scheduler. • As of Vista, scheduled task config files are stored as XML files in c:\Windows\system32\tasks\ • Authenticated users have RW access to this folder and can edit their own tasks.

  5. Modification • What stops users from elevating the context of their jobs? • Jobs are configured within the XML file to run as the user who created them in the case of non-admins. • A CRC32 check ensures that the XML config files are not modified after creation.

  6. What’s the problem? • CRC can catch accidental modification. • Intentional changes can be introduced that do not change the CRC. • A config file can be changed to elevate rights and then a properly constructed XML comment can be appended to the end of the file so that the CRC checks out ok.

  7. Method • Create a task as a standard user that will create a new user and add it to administrators. • Modify the XML config to run as System. • Calculate the end string needed to give the modified file the same CRC32 result as the original task. • Append the end string to the file. • Let it run. A new admin account is created.

  8. In the wild • This exploit was one of two exploits used by Stuxnet to elevate privileges. • This zero day was found to be present in all recent Microsoft operating systems and may have been actively used for years.

  9. The fix is in • A patch was implemented in late 2010. • A new layer of checking was done to rule out intentional modification. • A SHA256 hash was added on top of the CRC32, effectively preventing undetected modification.

  10. Case Study 2 • The second case is the sysret bug. • Security researchers discovered this flaw in Intel’s implementation of AMD’s sysret operation that allows for privilege escalation. • This impacted all Intel 64 bit architectures running AMD compiled code.

  11. What’s sysret? • Sysret is AMD’s 64 bit method of context switching between kernel and user levels or hypervisor and guest OSes. • The AMD implementation is secure. • Intel supported the AMD spec in a way that allowed a bad return address to be pushed into the return stack pointer in kernel mode.

  12. Why is this bad? • The bad address would be caught but within the context of the kernel or hypervisor, instead of the normal user level. • A protection fault would be triggered in an elevated state, leaving the process that triggered the fault with elevated status. • Attaching the running program to a process such as Explorer would give the logged in user kernel rights.

  13. Extent of the problem • All 64 bit Windows operating systems were impacted. • Xen, FreeBSD and NetBSD were also vulnerable. • Linux and OpenBSD had both patched the issue prior to its discovery. • Linux developers patched their OS 6 years prior but described the patch in such a way that no one noticed it might apply to other OSes. • Only a problem on Intel hardware.

  14. Reactions • Open source OSes were quick to release patches. • Microsoft took 3 months to release a patch. • Intel affirmed that the behaviour of its implementation of sysret is well documented and that it is up to the OS developers to handle it properly.

  15. In the wild? • Despite the fact the weakness had existed for at least 6 years prior to its discovery there were no known exploits associated with this bug. • Microsoft released a patch in mid-June of 2012. • Only systems that do not participate in automatic updates are considered at risk.

  16. StuxnetExploit References http://www.eset.com/us/resources/white-papers/Stuxnet_Under_the_Microscope.pdf http://vishnuvalentino.com/tips-and-trick/privilege-escalation-from-guest-to-administrator-windows7-windows2008/ http://technet.microsoft.com/en-us/security/bulletin/ms10-092

  17. Sysret Exploit References http://blog.xen.org/index.php/2012/06/13/the-intel-sysret-privilege-escalation/ http://blog.xen.org/index.php/2012/06/13/the-intel-sysret-privilege-escalation/ http://technet.microsoft.com/en-us/security/bulletin/MS12-042

More Related