#160 | pen20 – Debugging a faulty plugin in Drupal during a pentest

Phew, so I just spent my whole day debugging a supposedly RCE I got during an assessment. I’ll talk in this article about what happened and how I managed to debug a faulty plugin.


Long story short

So, I won’t explain how I got access to the admin page for obvious reasons but what happened is that I got administrative access on a Drupal and by trying to get an RCE, I bugged the application and the whole admin page wasn’t accessible.

The module I tried to load is “admin_toolbar_tools”, which adds some new features to the toolbar you see when you manage to log in as an administrator. The module was trying to load some route names inside the drupal core, which made the application crash and not display a page (only a stack trace/error).


Get the RCE

So the first step I needed to do is to get the RCE, which was kind of difficult because I was working totally blind and that I wasn’t able to get new CSRF tokens.

Fortunately, CSRF tokens are not one-use only on Drupal, meaning that I could call functions, the only conditions was for me to have navigated to that page before. But this time, unfortunately I didn’t navigate to “admin/modules/uninstall/”, which means that I couldn’t get the correct CSRF tokens.

To be able to execute code, I uploaded a code through “admin/modules/install” (which I navigated to, to show something to a friend). I uploaded a module that I modified to contain my code, in zip format. After the install I just had to launch the job by following a redirection.

The module got uncompressed and I managed to execute code by going to “./modules/attacker/attacker.php”.


Bypassing the WAF

The second challenge I had was that the application audited had a WAF which slowed down my exploitation path. To execute system commands, passthru was available however, and to evade the WAF I was able to cut my payload into multiple string (for example: passthru(‘i’.’d’);). Write another file which would do an eval(base64()) that would evade totally the WAF.

With code execution I was able to recover the login to the database and connect to it using PHP.


Debugging the application

That steps took the longest, I’ll describe here the main steps to disable a module with only a database access.

  • Recover the serialized data inside the table “config”, where “name” = “core.modules”.
  • Edit the serialized data to remove the faulty plugin, plus another problematic plugin (admin-toolbar-tools and toolbar)
  • Truncate all the cache_ tables, avoiding cache_forms (which wasn’t present anyway in my instance)
  • Connect to the admin interface and re-activate toolbar.

Here is the answer, and with all these steps, that’s how I spent my whole day, with the stress of potentially having to explain to the client I crashed his app! I got lucky and I was able to correct it in one day. That’s all for me for today, and that’s with a sigh of relief that I say, ’till next time!

Leave a Reply

Your email address will not be published. Required fields are marked *