a guest Aug 10th, 2016 3,128 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1.                 |                                             |
  2.                 | a  w r i t e u p  r e l e a s e  b y  r o l |
  3.                 |      ________  ___  ________  ________      |
  4.                 |     <_  __   \/   \/        \/ ____   \     |                  
  5.                 |      T  T<___/\___/\_  /\  _/\ \__j  _/     |
  6.                 |      |  |     T   T T /  \ T__\____  T      |
  7.                 |      |  |     |   | | \  / |T T   T  |      |
  8.                 |      l__j_____l___j_l__><__j| |   |  |      |
  9.                 |       T _______ T | ___j    | l___j  |      |
  10.                 |       | T   __T |_j l_______l________j      |
  11.                 |       | |   l_| |__ _______j                |
  12.                 |       | l_____j | T T                       |
  13.            ____ '     __l_________j_| |___                    `  ________
  14.            T  T  ___ / ____  TT  __Tj |  T     _/\_   ____/\_   / ____  T
  15.            |  | /   \\ \__j  ||  l____j  |   _/    \_/  \    \_ \ \__j  |
  16.            |  |_\___/_\____  ||    l__|  l___T  /\  T___/ /\  T__\____  |
  17.            |  | TT  T T   T  ||   _   |  ___j| /  \ |  T /  \ |T T   T  |
  18.            |  l ||  | l___j  ||   |   |  l___| \  / |  | \  / || l___j  |
  19.            l____jl__l________jl___l___j______j__><__j__j__><__jl________j
  20.             r   i   n   g     o   f     l   i   g   h   t   n   i   n   g
  22. #rtchurch ::
  24. Specific Secure Boot policies, when provisioned, allow for testsigning to be
  25. enabled, on any BCD object, including {bootmgr}. This also removes the NT loader
  26. options blacklist (AFAIK). (MS16-094 / CVE-2016-3287, and MS16-100 / CVE-2016-3320)
  28. Found by my123 (@never_released) and slipstream (@TheWack0lian)
  29. Writeup by slipstream (@TheWack0lian)
  31. First up, "Secure Boot policies". What are they exactly?
  33. As you know, secureboot is a part of the uefi firmware, when enabled, it only
  34. lets stuff run that's signed by a cert in db, and whose hash is not in dbx
  35. (revoked).
  37. As you probably also know, there are devices where secure boot can NOT be
  38. disabled by the user (Windows RT, HoloLens, Windows Phone, maybe Surface Hub,
  39. and maybe some IoTCore devices if such things actually exist -- not talking
  40. about the boards themselves which are not locked down at all by default, but end
  41. devices sold that may have secureboot locked on).
  43. But in some cases, the "shape" of secure boot needs to change a bit. For example
  44. in development, engineering, refurbishment, running flightsigned stuff (as of
  45. win10) etc. How to do that, with devices where secure boot is locked on?
  47. Enter the Secure Boot policy.
  49. It's a file in a binary format that's embedded within an ASN.1 blob, that is
  50. signed. It's loaded by bootmgr REALLY early into the windows boot process. It
  51. must be signed by a certificate in db. It gets loaded from a UEFI variable in
  52. the secureboot namespace (therefore, it can only be touched by boot services).
  53. There's a couple .efis signed by MS that can provision such a policy, that is,
  54. set the UEFI variable with its contents being the policy.
  56. What can policies do, you ask?
  58. They have two different types of rules. BCD rules, which override settings
  59. in the on-disk BCD, and registry rules, which contain configuration for the
  60. policy itself, plus configuration for other parts of boot services, etc. For
  61. example, one registry element was introduced in Windows 10 version 1607
  62. 'Redstone' which disables certificate expiry checking inside mobilestartup's
  63. .ffu flashing (ie, the "lightning bolt" windows phone flasher); and another one
  64. enables mobilestartup's USB mass storage mode. Other interesting registry
  65. rules change the shape of Code Integrity, ie, for a certain type of binary,
  66. it changes the certificates considered valid for that specific binary.
  68. (Alex Ionescu wrote a blog post that touches on Secure Boot policies. He teased a
  69. followup post that would be all about them, but that never came.)
  71. But, they must be signed by a cert in db. That is to say, Microsoft.
  73. Also, there is such a thing called DeviceID. It's the first 64 bits of a salted
  74. SHA-256 hash, of some UEFI PRNG output. It's used when applying policies on
  75. Windows Phone, and on Windows RT (mobilestartup sets it on Phone, and
  76. SecureBootDebug.efi when that's launched for the first time on RT). On Phone,
  77. the policy must be located in a specific place on EFIESP partition with the
  78. filename including the hex-form of the DeviceID. (With Redstone, this got
  79. changed to UnlockID, which is set by bootmgr, and is just the raw UEFI PRNG
  80. output.)
  82. Basically, bootmgr checks the policy when it loads, if it includes a DeviceID,
  83. which doesn't match the DeviceID of the device that bootmgr is running on, the
  84. policy will fail to load.
  86. Any policy that allows for enabling testsigning (MS calls these Retail Device
  87. Unlock / RDU policies, and to install them is unlocking a device), is supposed
  88. to be locked to a DeviceID (UnlockID on Redstone and above). Indeed, I have
  89. several policies (signed by the Windows Phone production certificate) like
  90. this, where the only differences are the included DeviceID, and the signature.
  92. If there is no valid policy installed, bootmgr falls back to using a default
  93. policy located in its resources. This policy is the one which blocks enabling
  94. testsigning, etc, using BCD rules.
  96. Now, for Microsoft's screwups.
  98. During the development of Windows 10 v1607 'Redstone', MS added a new type of
  99. secure boot policy. Namely, "supplemental" policies that are located in the
  100. EFIESP partition (rather than in a UEFI variable), and have their settings
  101. merged in, dependant on conditions (namely, that a certain "activation" policy
  102. is also in existance, and has been loaded in).
  104. Redstone's bootmgr.efi loads "legacy" policies (namely, a policy from UEFI
  105. variables) first. At a certain time in redstone dev, it did not do any further
  106. checks beyond signature / deviceID checks. (This has now changed, but see how
  107. the change is stupid)
  108. After loading the "legacy" policy, or a base policy from EFIESP partition, it
  109. then loads, checks and merges in the supplemental policies.
  111. See the issue here? If not, let me spell it out to you plain and clear.
  112. The "supplemental" policy contains new elements, for the merging conditions.
  113. These conditions are (well, at one time) unchecked by bootmgr when loading a
  114. legacy policy. And bootmgr of win10 v1511 and earlier certainly doesn't know
  115. about them. To those bootmgrs, it has just loaded in a perfectly valid, signed
  116. policy.
  118. The "supplemental" policy does NOT contain a DeviceID. And, because they were
  119. meant to be merged into a base policy, they don't contain any BCD rules either,
  120. which means that if they are loaded, you can enable testsigning. Not just for
  121. windows (to load unsigned driver, ie rootkit), but for the {bootmgr} element
  122. as well, which allows bootmgr to run what is effectively an unsigned .efi
  123. (ie bootkit)!!! (In practise, the .efi file must be signed, but it can be
  124. self-signed) You can see how this is very bad!! A backdoor, which MS put
  125. in to secure boot because they decided to not let the user turn it off in
  126. certain devices, allows for secure boot to be disabled everywhere!
  128. You can see the irony. Also the irony in that MS themselves provided us several
  129. nice "golden keys" (as the FBI would say ;) for us to use for that purpose :)
  131. About the FBI: are you reading this? If you are, then this is a perfect real
  132. world example about why your idea of backdooring cryptosystems with a "secure
  133. golden key" is very bad! Smarter people than me have been telling this to you
  134. for so long, it seems you have your fingers in your ears. You seriously don't
  135. understand still? Microsoft implemented a "secure golden key" system. And the
  136. golden keys got released from MS own stupidity. Now, what happens if you tell
  137. everyone to make a "secure golden key" system? Hopefully you can add 2+2...
  139. Anyway, enough about that little rant, wanted to add that to a writeup ever
  140. since this stuff was found ;)
  142. Anyway, MS's first patch attempt. I say "attempt" because it surely doesn't do
  143. anything useful. It blacklists (in boot.stl), most (not all!) of the policies.
  144. Now, about boot.stl. It's a file that gets cloned to a UEFI variable only boot
  145. services can touch, and only when the boot.stl signing time is later than the
  146. time this UEFI variable was set.
  147. However, this is done AFTER a secure boot policy gets loaded. Redstone's
  148. bootmgr has extra code to use the boot.stl in the UEFI variable to check
  149. policy revocation, but the bootmgrs of TH2 and earlier does NOT have such
  150. code.
  151. So, an attacker can just replace a later bootmgr with an earlier one.
  153. Another thing: I saw some additional code in the load-legacy-policy function in
  154. redstone 14381.rs1_release. Code that wasn't there in 14361. Code that
  155. specifically checked the policy being loaded for an element that meant this was
  156. a supplemental policy, and erroring out if so. So, if a system is running
  157. Windows 10 version 1607 or above, an attacker MUST replace bootmgr with
  158. an earlier one.
  160. On August 9th, 2016, another patch came about, this one was given the designation
  161. MS16-100 and CVE-2016-3320. This one updates dbx. The advisory says it revokes
  162. bootmgrs. The dbx update seems to add these SHA256 hashes (unless I screwed up
  163. my parsing):
  165. 075eea060589548ba060b2feed10da3c20c7fe9b17cd026b94e8a683b8115238
  166. 07e6c6a858646fb1efc67903fe28b116011f2367fe92e6be2b36999eff39d09e
  167. 09df5f4e511208ec78b96d12d08125fdb603868de39f6f72927852599b659c26
  168. 0bbb4392daac7ab89b30a4ac657531b97bfaab04f90b0dafe5f9b6eb90a06374
  169. 0c189339762df336ab3dd006a463df715a39cfb0f492465c600e6c6bd7bd898c
  170. 0d0dbeca6f29eca06f331a7d72e4884b12097fb348983a2a14a0d73f4f10140f
  171. 0dc9f3fb99962148c3ca833632758d3ed4fc8d0b0007b95b31e6528f2acd5bfc
  172. 106faceacfecfd4e303b74f480a08098e2d0802b936f8ec774ce21f31686689c
  173. 174e3a0b5b43c6a607bbd3404f05341e3dcf396267ce94f8b50e2e23a9da920c
  174. 18333429ff0562ed9f97033e1148dceee52dbe2e496d5410b5cfd6c864d2d10f
  175. 2b99cf26422e92fe365fbf4bc30d27086c9ee14b7a6fff44fb2f6b9001699939
  176. 2bbf2ca7b8f1d91f27ee52b6fb2a5dd049b85a2b9b529c5d6662068104b055f8
  177. 2c73d93325ba6dcbe589d4a4c63c5b935559ef92fbf050ed50c4e2085206f17d
  178. 2e70916786a6f773511fa7181fab0f1d70b557c6322ea923b2a8d3b92b51af7d
  179. 306628fa5477305728ba4a467de7d0387a54f569d3769fce5e75ec89d28d1593
  180. 3608edbaf5ad0f41a414a1777abf2faf5e670334675ec3995e6935829e0caad2
  181. 3841d221368d1583d75c0a02e62160394d6c4e0a6760b6f607b90362bc855b02
  182. 3fce9b9fdf3ef09d5452b0f95ee481c2b7f06d743a737971558e70136ace3e73
  183. 4397daca839e7f63077cb50c92df43bc2d2fb2a8f59f26fc7a0e4bd4d9751692
  184. 47cc086127e2069a86e03a6bef2cd410f8c55a6d6bdb362168c31b2ce32a5adf
  185. 518831fe7382b514d03e15c621228b8ab65479bd0cbfa3c5c1d0f48d9c306135
  186. 5ae949ea8855eb93e439dbc65bda2e42852c2fdf6789fa146736e3c3410f2b5c
  187. 6b1d138078e4418aa68deb7bb35e066092cf479eeb8ce4cd12e7d072ccb42f66
  188. 6c8854478dd559e29351b826c06cb8bfef2b94ad3538358772d193f82ed1ca11
  189. 6f1428ff71c9db0ed5af1f2e7bbfcbab647cc265ddf5b293cdb626f50a3a785e
  190. 71f2906fd222497e54a34662ab2497fcc81020770ff51368e9e3d9bfcbfd6375
  191. 726b3eb654046a30f3f83d9b96ce03f670e9a806d1708a0371e62dc49d2c23c1
  192. 72e0bd1867cf5d9d56ab158adf3bddbc82bf32a8d8aa1d8c5e2f6df29428d6d8
  193. 7827af99362cfaf0717dade4b1bfe0438ad171c15addc248b75bf8caa44bb2c5
  194. 81a8b965bb84d3876b9429a95481cc955318cfaa1412d808c8a33bfd33fff0e4
  195. 82db3bceb4f60843ce9d97c3d187cd9b5941cd3de8100e586f2bda5637575f67
  196. 895a9785f617ca1d7ed44fc1a1470b71f3f1223862d9ff9dcc3ae2df92163daf
  197. 8ad64859f195b5f58dafaa940b6a6167acd67a886e8f469364177221c55945b9
  198. 8bf434b49e00ccf71502a2cd900865cb01ec3b3da03c35be505fdf7bd563f521
  199. 8d8ea289cfe70a1c07ab7365cb28ee51edd33cf2506de888fbadd60ebf80481c
  200. 9998d363c491be16bd74ba10b94d9291001611736fdca643a36664bc0f315a42
  201. 9e4a69173161682e55fde8fef560eb88ec1ffedcaf04001f66c0caf707b2b734
  202. a6b5151f3655d3a2af0d472759796be4a4200e5495a7d869754c4848857408a7
  203. a7f32f508d4eb0fead9a087ef94ed1ba0aec5de6f7ef6ff0a62b93bedf5d458d
  204. ad6826e1946d26d3eaf3685c88d97d85de3b4dcb3d0ee2ae81c70560d13c5720
  205. aeebae3151271273ed95aa2e671139ed31a98567303a332298f83709a9d55aa1
  206. afe2030afb7d2cda13f9fa333a02e34f6751afec11b010dbcd441fdf4c4002b3
  207. b54f1ee636631fad68058d3b0937031ac1b90ccb17062a391cca68afdbe40d55
  208. b8f078d983a24ac433216393883514cd932c33af18e7dd70884c8235f4275736
  209. b97a0889059c035ff1d54b6db53b11b9766668d9f955247c028b2837d7a04cd9
  210. bc87a668e81966489cb508ee805183c19e6acd24cf17799ca062d2e384da0ea7
  211. c409bdac4775add8db92aa22b5b718fb8c94a1462c1fe9a416b95d8a3388c2fc
  212. c617c1a8b1ee2a811c28b5a81b4c83d7c98b5b0c27281d610207ebe692c2967f
  213. c90f336617b8e7f983975413c997f10b73eb267fd8a10cb9e3bdbfc667abdb8b
  214. cb6b858b40d3a098765815b592c1514a49604fafd60819da88d7a76e9778fef7
  215. ce3bfabe59d67ce8ac8dfd4a16f7c43ef9c224513fbc655957d735fa29f540ce
  216. d8cbeb9735f5672b367e4f96cdc74969615d17074ae96c724d42ce0216f8f3fa
  217. e92c22eb3b5642d65c1ec2caf247d2594738eebb7fb3841a44956f59e2b0d1fa
  218. fddd6e3d29ea84c7743dad4a1bdbc700b5fec1b391f932409086acc71dd6dbd8
  219. fe63a84f782cc9d3fcf2ccf9fc11fbd03760878758d26285ed12669bdc6e6d01
  220. fecfb232d12e994b6d485d2c7167728aa5525984ad5ca61e7516221f079a1436
  221. ca171d614a8d7e121c93948cd0fe55d39981f9d11aa96e03450a415227c2c65b
  222. 55b99b0de53dbcfe485aa9c737cf3fb616ef3d91fab599aa7cab19eda763b5ba
  223. 77dd190fa30d88ff5e3b011a0ae61e6209780c130b535ecb87e6f0888a0b6b2f
  224. c83cb13922ad99f560744675dd37cc94dcad5a1fcba6472fee341171d939e884
  225. 3b0287533e0cc3d0ec1aa823cbf0a941aad8721579d1c499802dd1c3a636b8a9
  226. 939aeef4f5fa51e23340c3f2e49048ce8872526afdf752c3a7f3a3f2bc9f6049
  227. 64575bd912789a2e14ad56f6341f52af6bf80cf94400785975e9f04e2d64d745
  228. 45c7c8ae750acfbb48fc37527d6412dd644daed8913ccd8a24c94d856967df8e
  230. I checked the hash in the signature of several bootmgrs of several
  231. architectures against this list, and found no matches. So either this
  232. revokes many "obscure" bootmgrs and bootmgfws, or I'm checking the wrong hash.
  234. Either way, it'd be impossible in practise for MS to revoke every bootmgr
  235. earlier than a certain point, as they'd break install media, recovery partitions,
  236. backups, etc.
  238. - RoL
  240. disclosure timeline:
  241. ~march-april 2016 - found initial policy, contacted MSRC
  242. ~april 2016 - MSRC reply: wontfix, started analysis and reversing, working on
  243.   almost-silent (3 reboots needed) PoC for possible emfcamp demonstration
  244. ~june-july 2016 - MSRC reply again, finally realising: bug bounty awarded
  245. july 2016 - initial fix - fix analysed, deemed inadequate. reversed later rs1
  246.   bootmgr, noticed additional inadequate mitigation
  247. august 2016 - mini-talk about the issue at emfcamp, second fix, full writeup
  248.   release
  251. credits:
  252. my123 (@never_released) -- found initial policy set, tested on surface rt
  253. slipstream (@TheWack0lian) -- analysis of policies, reversing bootmgr/
  254.   mobilestartup/etc, found even more policies, this writeup.
  256. tiny-tro credits:
  257. code and design: slipstream/RoL
  258. font: dMG/Up Rough & Divine Stylers
  259. awesome chiptune: bzl/cRO <3
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand