Nightmare-Eclipse has published two new toys to GitHub: GreenPlasma and YellowKey.
-
Nightmare-Eclipse has published two new toys to GitHub: GreenPlasma and YellowKey.
TL;DR:
- GreenPlasma looks interesting, but it's not a complete exploit. It's at best a building block toward LPE on Windows.
- YellowKey is a Windows login bypass for an attacker with physical access. Use case: Your roomate wants to get into your roomate's poorly protected (potentially work-owned) laptop. Mitigation: Use Bitlocker with a PIN. (Note: The YellowKey author disagrees that PIN is a protection
)
1) GreenPlasma
Here , an unprivileged user can create an arbitrary memory section in an object. While the first time I tried it it hung at the UAC prompt, but subsequent attempts worked to go from low-privileged to creating a\CSRSS_TEST_SECTIONobject.
It is worth noting that the PoC as it is does not have the bits that would turn it into a true LPE, as that is left as an exercise to the user.2) YellowKey
This one is a bit hand-wavy to me, But I eventually was able to reproduce it. Via an attached USB drive. I could NOT reproduce it via putting theFsTxdirectory on the EFI partition. Potentially because theFsTxreplay happened before my triggering of Recovery. I was able to reproduce with a USB drive attached.The target is a TPM-only bitlocker, which is known to be insecure. The use case is that, with physical access, you can access the filesystem with root privileges. Which even TPM-only bitlocker would prevent.
There is a thread on Twitter that claims to have reverse engineered the YellowKey Bitlocker bypass. And it talks about
RecoverySimulation.iniand how it skips re-locking a bitlocker drive. The thing about this is:
1) ThisRecoverySimulation.inistuff was talked about publicly last year
2) The actual bits in the YellowKey GitHub repo are the contents of anFsTxdirectory. Which appears to be be related to Transactional NTFS, which uses CLFS under the hood. (The files parse with python'sdissect.clfs). Also note that by looking at Windows'fstx.dll, we can see code that explicitly looks for\System Volume Information\FsTxin theFsTxFindSessions()function.Microsoft themselves have this to say about TxF
:While TxF is a powerful set of APIs, there has been extremely limited developer interest in this API platform since Windows Vista primarily due to its complexity and various nuances which developers need to consider as part of application development. As a result, Microsoft is considering deprecating TxF APIs in a future version of Windows to focus development and maintenance efforts on other features and APIs which have more value to a larger majority of customers.
And if one looks at the contents of this
FsTxdirectory in the GitHub repo, there are no strings related toRecoverySimulation.iniin it at all. Only of interest is perhaps:\??\C:\Windows\win.ini
and\??\X:\Windows\System32\winpeshl.iniWhere
X:\Windows\System32\winpeshl.iniis what controls what WinRE does when it fires up.But anyway, yes it works.
But what's intriguing to me is: Why can the presence a\System Volume Information\FsTxdirectory on one volume affect the contents of ANOTHER VOLUME when it's replayed?In a normal WinRE session, you have a
X:\Windows\System32directory that has awinpeshl.inifile in it:[LaunchApp]
AppPath=X:\sources\recovery\recenv.exeHowever, with the YellowKey exploit, it looks like Transactional NTFS bits on a USB Drive are able to delete the
winpeshl.inifile on ANOTHER DRIVE (X:). And we get a cmd.exe prompt, with bitlocker unlocked instead of the expected Windows Recovery environment. While the TPM-only Bitlocker bypass is indeed interesting, I think the buried lede here is that a\System Volume Information\FsTxdirectory on one volume has the ability to modify the contents of another volume when it is replayed. To me, this in and of itself sounds like a vulnerability.
-
Nightmare-Eclipse has published two new toys to GitHub: GreenPlasma and YellowKey.
TL;DR:
- GreenPlasma looks interesting, but it's not a complete exploit. It's at best a building block toward LPE on Windows.
- YellowKey is a Windows login bypass for an attacker with physical access. Use case: Your roomate wants to get into your roomate's poorly protected (potentially work-owned) laptop. Mitigation: Use Bitlocker with a PIN. (Note: The YellowKey author disagrees that PIN is a protection )
1) GreenPlasma
Here , an unprivileged user can create an arbitrary memory section in an object. While the first time I tried it it hung at the UAC prompt, but subsequent attempts worked to go from low-privileged to creating a\CSRSS_TEST_SECTIONobject.
It is worth noting that the PoC as it is does not have the bits that would turn it into a true LPE, as that is left as an exercise to the user.2) YellowKey
This one is a bit hand-wavy to me, But I eventually was able to reproduce it. Via an attached USB drive. I could NOT reproduce it via putting theFsTxdirectory on the EFI partition. Potentially because theFsTxreplay happened before my triggering of Recovery. I was able to reproduce with a USB drive attached.The target is a TPM-only bitlocker, which is known to be insecure. The use case is that, with physical access, you can access the filesystem with root privileges. Which even TPM-only bitlocker would prevent.
There is a thread on Twitter that claims to have reverse engineered the YellowKey Bitlocker bypass. And it talks about
RecoverySimulation.iniand how it skips re-locking a bitlocker drive. The thing about this is:
1) ThisRecoverySimulation.inistuff was talked about publicly last year
2) The actual bits in the YellowKey GitHub repo are the contents of anFsTxdirectory. Which appears to be be related to Transactional NTFS, which uses CLFS under the hood. (The files parse with python'sdissect.clfs). Also note that by looking at Windows'fstx.dll, we can see code that explicitly looks for\System Volume Information\FsTxin theFsTxFindSessions()function.Microsoft themselves have this to say about TxF
:While TxF is a powerful set of APIs, there has been extremely limited developer interest in this API platform since Windows Vista primarily due to its complexity and various nuances which developers need to consider as part of application development. As a result, Microsoft is considering deprecating TxF APIs in a future version of Windows to focus development and maintenance efforts on other features and APIs which have more value to a larger majority of customers.
And if one looks at the contents of this
FsTxdirectory in the GitHub repo, there are no strings related toRecoverySimulation.iniin it at all. Only of interest is perhaps:\??\C:\Windows\win.ini
and\??\X:\Windows\System32\winpeshl.iniWhere
X:\Windows\System32\winpeshl.iniis what controls what WinRE does when it fires up.But anyway, yes it works.
But what's intriguing to me is: Why can the presence a\System Volume Information\FsTxdirectory on one volume affect the contents of ANOTHER VOLUME when it's replayed?In a normal WinRE session, you have a
X:\Windows\System32directory that has awinpeshl.inifile in it:[LaunchApp]
AppPath=X:\sources\recovery\recenv.exeHowever, with the YellowKey exploit, it looks like Transactional NTFS bits on a USB Drive are able to delete the
winpeshl.inifile on ANOTHER DRIVE (X:). And we get a cmd.exe prompt, with bitlocker unlocked instead of the expected Windows Recovery environment. While the TPM-only Bitlocker bypass is indeed interesting, I think the buried lede here is that a\System Volume Information\FsTxdirectory on one volume has the ability to modify the contents of another volume when it is replayed. To me, this in and of itself sounds like a vulnerability.> TPM-only bitlocker is known to not be very secure, and if you have TPM+PIN, then you can't get to Windows Recovery Environment Agent without the PIN. So again, where's the bypass?
The TPM-only mode works well to lock employees out of their corporate laptops (users can't mount the drive on another computer or in another OS using a user password) and with no requirement to create another strong password.
Also, all WinRE bypasses affect the TPM plus Network Key mode (seamless boot when the computer is in the trusted wired network: both the network server and TPM unwrap the encryption key).
---
It's interesting that Microsoft disguises some vulnerability descriptions as EoP, not as SfB.
-
Nightmare-Eclipse has published two new toys to GitHub: GreenPlasma and YellowKey.
TL;DR:
- GreenPlasma looks interesting, but it's not a complete exploit. It's at best a building block toward LPE on Windows.
- YellowKey is a Windows login bypass for an attacker with physical access. Use case: Your roomate wants to get into your roomate's poorly protected (potentially work-owned) laptop. Mitigation: Use Bitlocker with a PIN. (Note: The YellowKey author disagrees that PIN is a protection )
1) GreenPlasma
Here , an unprivileged user can create an arbitrary memory section in an object. While the first time I tried it it hung at the UAC prompt, but subsequent attempts worked to go from low-privileged to creating a\CSRSS_TEST_SECTIONobject.
It is worth noting that the PoC as it is does not have the bits that would turn it into a true LPE, as that is left as an exercise to the user.2) YellowKey
This one is a bit hand-wavy to me, But I eventually was able to reproduce it. Via an attached USB drive. I could NOT reproduce it via putting theFsTxdirectory on the EFI partition. Potentially because theFsTxreplay happened before my triggering of Recovery. I was able to reproduce with a USB drive attached.The target is a TPM-only bitlocker, which is known to be insecure. The use case is that, with physical access, you can access the filesystem with root privileges. Which even TPM-only bitlocker would prevent.
There is a thread on Twitter that claims to have reverse engineered the YellowKey Bitlocker bypass. And it talks about
RecoverySimulation.iniand how it skips re-locking a bitlocker drive. The thing about this is:
1) ThisRecoverySimulation.inistuff was talked about publicly last year
2) The actual bits in the YellowKey GitHub repo are the contents of anFsTxdirectory. Which appears to be be related to Transactional NTFS, which uses CLFS under the hood. (The files parse with python'sdissect.clfs). Also note that by looking at Windows'fstx.dll, we can see code that explicitly looks for\System Volume Information\FsTxin theFsTxFindSessions()function.Microsoft themselves have this to say about TxF
:While TxF is a powerful set of APIs, there has been extremely limited developer interest in this API platform since Windows Vista primarily due to its complexity and various nuances which developers need to consider as part of application development. As a result, Microsoft is considering deprecating TxF APIs in a future version of Windows to focus development and maintenance efforts on other features and APIs which have more value to a larger majority of customers.
And if one looks at the contents of this
FsTxdirectory in the GitHub repo, there are no strings related toRecoverySimulation.iniin it at all. Only of interest is perhaps:\??\C:\Windows\win.ini
and\??\X:\Windows\System32\winpeshl.iniWhere
X:\Windows\System32\winpeshl.iniis what controls what WinRE does when it fires up.But anyway, yes it works.
But what's intriguing to me is: Why can the presence a\System Volume Information\FsTxdirectory on one volume affect the contents of ANOTHER VOLUME when it's replayed?In a normal WinRE session, you have a
X:\Windows\System32directory that has awinpeshl.inifile in it:[LaunchApp]
AppPath=X:\sources\recovery\recenv.exeHowever, with the YellowKey exploit, it looks like Transactional NTFS bits on a USB Drive are able to delete the
winpeshl.inifile on ANOTHER DRIVE (X:). And we get a cmd.exe prompt, with bitlocker unlocked instead of the expected Windows Recovery environment. While the TPM-only Bitlocker bypass is indeed interesting, I think the buried lede here is that a\System Volume Information\FsTxdirectory on one volume has the ability to modify the contents of another volume when it is replayed. To me, this in and of itself sounds like a vulnerability.@wdormann, these bypasses are very close to login/lock screen bypasses (after the usual boot) and kiosk mode escapes (in WinRE).
-
Nightmare-Eclipse has published two new toys to GitHub: GreenPlasma and YellowKey.
TL;DR:
- GreenPlasma looks interesting, but it's not a complete exploit. It's at best a building block toward LPE on Windows.
- YellowKey is a Windows login bypass for an attacker with physical access. Use case: Your roomate wants to get into your roomate's poorly protected (potentially work-owned) laptop. Mitigation: Use Bitlocker with a PIN. (Note: The YellowKey author disagrees that PIN is a protection )
1) GreenPlasma
Here , an unprivileged user can create an arbitrary memory section in an object. While the first time I tried it it hung at the UAC prompt, but subsequent attempts worked to go from low-privileged to creating a\CSRSS_TEST_SECTIONobject.
It is worth noting that the PoC as it is does not have the bits that would turn it into a true LPE, as that is left as an exercise to the user.2) YellowKey
This one is a bit hand-wavy to me, But I eventually was able to reproduce it. Via an attached USB drive. I could NOT reproduce it via putting theFsTxdirectory on the EFI partition. Potentially because theFsTxreplay happened before my triggering of Recovery. I was able to reproduce with a USB drive attached.The target is a TPM-only bitlocker, which is known to be insecure. The use case is that, with physical access, you can access the filesystem with root privileges. Which even TPM-only bitlocker would prevent.
There is a thread on Twitter that claims to have reverse engineered the YellowKey Bitlocker bypass. And it talks about
RecoverySimulation.iniand how it skips re-locking a bitlocker drive. The thing about this is:
1) ThisRecoverySimulation.inistuff was talked about publicly last year
2) The actual bits in the YellowKey GitHub repo are the contents of anFsTxdirectory. Which appears to be be related to Transactional NTFS, which uses CLFS under the hood. (The files parse with python'sdissect.clfs). Also note that by looking at Windows'fstx.dll, we can see code that explicitly looks for\System Volume Information\FsTxin theFsTxFindSessions()function.Microsoft themselves have this to say about TxF
:While TxF is a powerful set of APIs, there has been extremely limited developer interest in this API platform since Windows Vista primarily due to its complexity and various nuances which developers need to consider as part of application development. As a result, Microsoft is considering deprecating TxF APIs in a future version of Windows to focus development and maintenance efforts on other features and APIs which have more value to a larger majority of customers.
And if one looks at the contents of this
FsTxdirectory in the GitHub repo, there are no strings related toRecoverySimulation.iniin it at all. Only of interest is perhaps:\??\C:\Windows\win.ini
and\??\X:\Windows\System32\winpeshl.iniWhere
X:\Windows\System32\winpeshl.iniis what controls what WinRE does when it fires up.But anyway, yes it works.
But what's intriguing to me is: Why can the presence a\System Volume Information\FsTxdirectory on one volume affect the contents of ANOTHER VOLUME when it's replayed?In a normal WinRE session, you have a
X:\Windows\System32directory that has awinpeshl.inifile in it:[LaunchApp]
AppPath=X:\sources\recovery\recenv.exeHowever, with the YellowKey exploit, it looks like Transactional NTFS bits on a USB Drive are able to delete the
winpeshl.inifile on ANOTHER DRIVE (X:). And we get a cmd.exe prompt, with bitlocker unlocked instead of the expected Windows Recovery environment. While the TPM-only Bitlocker bypass is indeed interesting, I think the buried lede here is that a\System Volume Information\FsTxdirectory on one volume has the ability to modify the contents of another volume when it is replayed. To me, this in and of itself sounds like a vulnerability.@wdormann YellowKey works fine on my laptop β copied the FsTx folder to System Volume Information directory on my sysresccd USB drive (2GB FAT32), Shift+restart, held Ctrl until recovery environment booted to command prompt. Unlocked
partition, predictably did not unlock D:.
-
@wdormann YellowKey works fine on my laptop β copied the FsTx folder to System Volume Information directory on my sysresccd USB drive (2GB FAT32), Shift+restart, held Ctrl until recovery environment booted to command prompt. Unlocked
partition, predictably did not unlock D:.Worked fine here. If the backdoor works you habe an open system shell before any menue. You can than use diskpart to mount the internal drive
-
Nightmare-Eclipse has published two new toys to GitHub: GreenPlasma and YellowKey.
TL;DR:
- GreenPlasma looks interesting, but it's not a complete exploit. It's at best a building block toward LPE on Windows.
- YellowKey is a Windows login bypass for an attacker with physical access. Use case: Your roomate wants to get into your roomate's poorly protected (potentially work-owned) laptop. Mitigation: Use Bitlocker with a PIN. (Note: The YellowKey author disagrees that PIN is a protection )
1) GreenPlasma
Here , an unprivileged user can create an arbitrary memory section in an object. While the first time I tried it it hung at the UAC prompt, but subsequent attempts worked to go from low-privileged to creating a\CSRSS_TEST_SECTIONobject.
It is worth noting that the PoC as it is does not have the bits that would turn it into a true LPE, as that is left as an exercise to the user.2) YellowKey
This one is a bit hand-wavy to me, But I eventually was able to reproduce it. Via an attached USB drive. I could NOT reproduce it via putting theFsTxdirectory on the EFI partition. Potentially because theFsTxreplay happened before my triggering of Recovery. I was able to reproduce with a USB drive attached.The target is a TPM-only bitlocker, which is known to be insecure. The use case is that, with physical access, you can access the filesystem with root privileges. Which even TPM-only bitlocker would prevent.
There is a thread on Twitter that claims to have reverse engineered the YellowKey Bitlocker bypass. And it talks about
RecoverySimulation.iniand how it skips re-locking a bitlocker drive. The thing about this is:
1) ThisRecoverySimulation.inistuff was talked about publicly last year
2) The actual bits in the YellowKey GitHub repo are the contents of anFsTxdirectory. Which appears to be be related to Transactional NTFS, which uses CLFS under the hood. (The files parse with python'sdissect.clfs). Also note that by looking at Windows'fstx.dll, we can see code that explicitly looks for\System Volume Information\FsTxin theFsTxFindSessions()function.Microsoft themselves have this to say about TxF
:While TxF is a powerful set of APIs, there has been extremely limited developer interest in this API platform since Windows Vista primarily due to its complexity and various nuances which developers need to consider as part of application development. As a result, Microsoft is considering deprecating TxF APIs in a future version of Windows to focus development and maintenance efforts on other features and APIs which have more value to a larger majority of customers.
And if one looks at the contents of this
FsTxdirectory in the GitHub repo, there are no strings related toRecoverySimulation.iniin it at all. Only of interest is perhaps:\??\C:\Windows\win.ini
and\??\X:\Windows\System32\winpeshl.iniWhere
X:\Windows\System32\winpeshl.iniis what controls what WinRE does when it fires up.But anyway, yes it works.
But what's intriguing to me is: Why can the presence a\System Volume Information\FsTxdirectory on one volume affect the contents of ANOTHER VOLUME when it's replayed?In a normal WinRE session, you have a
X:\Windows\System32directory that has awinpeshl.inifile in it:[LaunchApp]
AppPath=X:\sources\recovery\recenv.exeHowever, with the YellowKey exploit, it looks like Transactional NTFS bits on a USB Drive are able to delete the
winpeshl.inifile on ANOTHER DRIVE (X:). And we get a cmd.exe prompt, with bitlocker unlocked instead of the expected Windows Recovery environment. While the TPM-only Bitlocker bypass is indeed interesting, I think the buried lede here is that a\System Volume Information\FsTxdirectory on one volume has the ability to modify the contents of another volume when it is replayed. To me, this in and of itself sounds like a vulnerability.@wdormann "While TxF is a powerful set of APIs, there has been extremely limited developer interest in this API platform since Windows Vista primarily due to its complexity and various nuances which developers need to consider as part of application development. As a result, Microsoft is considering deprecating TxF APIs in a future version of Windows..." Wonder what "nuances" means here?
-
Nightmare-Eclipse has published two new toys to GitHub: GreenPlasma and YellowKey.
TL;DR:
- GreenPlasma looks interesting, but it's not a complete exploit. It's at best a building block toward LPE on Windows.
- YellowKey is a Windows login bypass for an attacker with physical access. Use case: Your roomate wants to get into your roomate's poorly protected (potentially work-owned) laptop. Mitigation: Use Bitlocker with a PIN. (Note: The YellowKey author disagrees that PIN is a protection )
1) GreenPlasma
Here , an unprivileged user can create an arbitrary memory section in an object. While the first time I tried it it hung at the UAC prompt, but subsequent attempts worked to go from low-privileged to creating a\CSRSS_TEST_SECTIONobject.
It is worth noting that the PoC as it is does not have the bits that would turn it into a true LPE, as that is left as an exercise to the user.2) YellowKey
This one is a bit hand-wavy to me, But I eventually was able to reproduce it. Via an attached USB drive. I could NOT reproduce it via putting theFsTxdirectory on the EFI partition. Potentially because theFsTxreplay happened before my triggering of Recovery. I was able to reproduce with a USB drive attached.The target is a TPM-only bitlocker, which is known to be insecure. The use case is that, with physical access, you can access the filesystem with root privileges. Which even TPM-only bitlocker would prevent.
There is a thread on Twitter that claims to have reverse engineered the YellowKey Bitlocker bypass. And it talks about
RecoverySimulation.iniand how it skips re-locking a bitlocker drive. The thing about this is:
1) ThisRecoverySimulation.inistuff was talked about publicly last year
2) The actual bits in the YellowKey GitHub repo are the contents of anFsTxdirectory. Which appears to be be related to Transactional NTFS, which uses CLFS under the hood. (The files parse with python'sdissect.clfs). Also note that by looking at Windows'fstx.dll, we can see code that explicitly looks for\System Volume Information\FsTxin theFsTxFindSessions()function.Microsoft themselves have this to say about TxF
:While TxF is a powerful set of APIs, there has been extremely limited developer interest in this API platform since Windows Vista primarily due to its complexity and various nuances which developers need to consider as part of application development. As a result, Microsoft is considering deprecating TxF APIs in a future version of Windows to focus development and maintenance efforts on other features and APIs which have more value to a larger majority of customers.
And if one looks at the contents of this
FsTxdirectory in the GitHub repo, there are no strings related toRecoverySimulation.iniin it at all. Only of interest is perhaps:\??\C:\Windows\win.ini
and\??\X:\Windows\System32\winpeshl.iniWhere
X:\Windows\System32\winpeshl.iniis what controls what WinRE does when it fires up.But anyway, yes it works.
But what's intriguing to me is: Why can the presence a\System Volume Information\FsTxdirectory on one volume affect the contents of ANOTHER VOLUME when it's replayed?In a normal WinRE session, you have a
X:\Windows\System32directory that has awinpeshl.inifile in it:[LaunchApp]
AppPath=X:\sources\recovery\recenv.exeHowever, with the YellowKey exploit, it looks like Transactional NTFS bits on a USB Drive are able to delete the
winpeshl.inifile on ANOTHER DRIVE (X:). And we get a cmd.exe prompt, with bitlocker unlocked instead of the expected Windows Recovery environment. While the TPM-only Bitlocker bypass is indeed interesting, I think the buried lede here is that a\System Volume Information\FsTxdirectory on one volume has the ability to modify the contents of another volume when it is replayed. To me, this in and of itself sounds like a vulnerability.P.S.
> The YellowKey author disagrees that PIN is a protection
Since early WinRE bypasses, Microsoft treats the "my PIN is known to the attacker, in the TPM+PIN configuration" situation as within the threat model. (IMO, this is not 2FA with one factor known to the attacker, but something similar.)
-
Nightmare-Eclipse has published two new toys to GitHub: GreenPlasma and YellowKey.
TL;DR:
- GreenPlasma looks interesting, but it's not a complete exploit. It's at best a building block toward LPE on Windows.
- YellowKey is a Windows login bypass for an attacker with physical access. Use case: Your roomate wants to get into your roomate's poorly protected (potentially work-owned) laptop. Mitigation: Use Bitlocker with a PIN. (Note: The YellowKey author disagrees that PIN is a protection )
1) GreenPlasma
Here , an unprivileged user can create an arbitrary memory section in an object. While the first time I tried it it hung at the UAC prompt, but subsequent attempts worked to go from low-privileged to creating a\CSRSS_TEST_SECTIONobject.
It is worth noting that the PoC as it is does not have the bits that would turn it into a true LPE, as that is left as an exercise to the user.2) YellowKey
This one is a bit hand-wavy to me, But I eventually was able to reproduce it. Via an attached USB drive. I could NOT reproduce it via putting theFsTxdirectory on the EFI partition. Potentially because theFsTxreplay happened before my triggering of Recovery. I was able to reproduce with a USB drive attached.The target is a TPM-only bitlocker, which is known to be insecure. The use case is that, with physical access, you can access the filesystem with root privileges. Which even TPM-only bitlocker would prevent.
There is a thread on Twitter that claims to have reverse engineered the YellowKey Bitlocker bypass. And it talks about
RecoverySimulation.iniand how it skips re-locking a bitlocker drive. The thing about this is:
1) ThisRecoverySimulation.inistuff was talked about publicly last year
2) The actual bits in the YellowKey GitHub repo are the contents of anFsTxdirectory. Which appears to be be related to Transactional NTFS, which uses CLFS under the hood. (The files parse with python'sdissect.clfs). Also note that by looking at Windows'fstx.dll, we can see code that explicitly looks for\System Volume Information\FsTxin theFsTxFindSessions()function.Microsoft themselves have this to say about TxF
:While TxF is a powerful set of APIs, there has been extremely limited developer interest in this API platform since Windows Vista primarily due to its complexity and various nuances which developers need to consider as part of application development. As a result, Microsoft is considering deprecating TxF APIs in a future version of Windows to focus development and maintenance efforts on other features and APIs which have more value to a larger majority of customers.
And if one looks at the contents of this
FsTxdirectory in the GitHub repo, there are no strings related toRecoverySimulation.iniin it at all. Only of interest is perhaps:\??\C:\Windows\win.ini
and\??\X:\Windows\System32\winpeshl.iniWhere
X:\Windows\System32\winpeshl.iniis what controls what WinRE does when it fires up.But anyway, yes it works.
But what's intriguing to me is: Why can the presence a\System Volume Information\FsTxdirectory on one volume affect the contents of ANOTHER VOLUME when it's replayed?In a normal WinRE session, you have a
X:\Windows\System32directory that has awinpeshl.inifile in it:[LaunchApp]
AppPath=X:\sources\recovery\recenv.exeHowever, with the YellowKey exploit, it looks like Transactional NTFS bits on a USB Drive are able to delete the
winpeshl.inifile on ANOTHER DRIVE (X:). And we get a cmd.exe prompt, with bitlocker unlocked instead of the expected Windows Recovery environment. While the TPM-only Bitlocker bypass is indeed interesting, I think the buried lede here is that a\System Volume Information\FsTxdirectory on one volume has the ability to modify the contents of another volume when it is replayed. To me, this in and of itself sounds like a vulnerability.Note that I've found the
hold CRTL and do NOT lift your finger off itpart of YellowKey to be completely unnecessary.From the beginning, I wondered why that was even part of the instructions (what does it accomplish?). And I guess the answer to that question is: Nothing?
β
οΈ -
R relay@relay.infosec.exchange shared this topic
