13 solves / 200 points difficulty: Medium Un administrateur du site a voulu jouer au développeur et a introduit une vulnérabilité dans le CMS ultra sécurisé WordPress. Pouvez-vous retrouver cette vulnérabilité et exfiltrer le flag ? url: http://web-vxslkw.inst.malicecyber.com/
For this challenge, as the name suggests, we have to exploit an XXE to get our way. With a first recon on the website, we could find several details that's indicating us where to go.
With those screens, It made obvious that we have to exploit the xmlrpc.php endpoint on the WordPress website. At this point, we can think about a lot of common WordPress exploits, but keep in mind that it's must be an implementation error as the post says. So, trying a simple XXE on xmlrpc.php gives us the following output:
Decoding the output:
Nice! We have exfiltrate /etc/passwd file using Error based XXE. Now, we need to dump more specific file to find what to do next. However, several issues make it very complicated:
Yes, in fact, as you probably already see on the previous screen, we haven't exfiltrated the whole /etc/passwd file. Obviously, we need to be able to bypass this security to continue. After searching and reading a lot of docs, I found a way to exfiltrate files using FTP. The problem ? No one tool makes it easy to exploit and it would be very long to dump the whole site if needed. So, I decided to create a tool to do exactly this! (I won't explain much more about it on this writeups, I will release it on github and write an article about FTP exfiltration in a few days)
Exemple of usage:
Well, now that we can dump everything, let's try to get the home page.
As we can see, it uses /startup.sh file at startup.
The script seems to add WordPress plugin using a zip file.
Now that we have the vulnerable plugin in local, we need to find a way to exploit it. Navigating inside all files, we could find those information.
As we can see, the plugin contains a read_system_logs function which can be used to interact with the fs. Moreover, the function seems to be very vulnerable to injection using ..././ instead of ../ to path transversal. The only problem that we face now, is that wordpress plugins can't be called directly.
Continue reading admin-logs plugin files, we can fin something very interesting. The read_system_logs function as been added to 'wp_ajax_nopriv' hook which permit us to call it directly using admin-ajax.php endpoint. (More information: https://developer.wordpress.org/reference/hooks/wp_ajax_nopriv_action/)
Obviously, we need can't use it without having localhost address, but using the XXE won't be difficult to pass.
Well, now that we have everything, let's use our XXE to flag this challenge.