Exploit -ERR unknown command 'MODULE'

[VBoucher]

Steps to reproduce

1. Setup server with redis 4.0.9
2. Open Wireshark with IP of server
3. Open metasploit
4. use exploit/linux/redis/redis_unauth_exec
5. Setup RHOST as remote host, SRVHOST as localhost and LHOST as localhost
6. run
7. Look at wireshark TCP Stream
8. -ERR unknown command 'MODULE'

The server is from HackTheBox VM Postman.

Expected behavior

Exploit says 4.x / 5.x. My redis server says 4.0.9. Payload should go through. Reverse shell should be working.

Current behavior

In Metasploit :
Started reverse TCP handler on [LOCAL_IP]:4444
[REMOTE_IP]:6379 - Compile redis module extension file
[REMOTE_IPIP]:6379 - Payload generated successfully!
[REMOTE_IPIP]:6379 - Listening on [LOCAL_IP]:6379
[REMOTE_IPIP]:6379 - Rogue server close...
[REMOTE_IPIP]:6379 - Sending command to trigger payload.
[REMOTE_IPIP]:6379 - This exploit may require manual cleanup of './jipclzog.so' on the target
Exploit completed, but no session was created.

From redis itself (Wireshark) :
-ERR unknown command 'MODULE'.

System stuff

Metasploit version

Framework: 5.0.59-dev
Console : 5.0.59-dev

I installed Metasploit with:

• Kali package via apt
• Omnibus installer (nightly)
• Commercial/Community installer (from http://www.rapid7.com/products/metasploit/download.jsp)
• Source install (please specify ruby version)

OS

Kali Linux

[space-r7]

You need to set the LHOST and SRVHOST to ip addresses that are reachable from your target.

[VBoucher]

I did. I set LHOST and SRVHOST to my ip address, which is reachable from my target. (Not "localhost"... sorry about that)

[blindpanic]

This exploit does not work with the postman ctf. There is another way.

[VBoucher]

Alright but shouldn't this exploit be renamed so that it excludes this version? The current name is 4.X / 5.X but 4.0.9 it part of 4.X. Should the version be more specific?

[wvu]

@blindpanic is saying the exploit does not work with the CTF. Let's try to avoid any spoilers here, thanks.

[VBoucher]

Found another way. I don't think you understood my comment (which wasn't about giving any spoiler) but nevermind.

[wvu]

@VBoucher: Yes, you are correct, the version should probably be more specific. The version range that's affected is likely in the advisory somewhere. It'd be a worthy update to the documentation.

[bcoles]

The module should also be renamed from redis_unauth_exec, as it is not an unauthenticated exploit (#12143).

[lyghtnox]

The "bug" mentioned in this issue has nothing to do with the versioning. The Postman machine on HTB had a specific configuration to prevent the attack as stated by 0xdf in his blogpost.
There is no need to update the documentation.

[wvu]

Thanks for confirming, @lyghtnox. My comment was more general than that.

While there may not be a need to update the documentation to exclude 4.0.9, which you've proven to be a false negative, we absolutely should be as specific as we can in listing affected versions. This goes for all modules.

"4.x and 5.x" may be accurate, but it's not precise, and it can lead to situations like this. The functionality this module abuses was added in a specific version or commit. @Green-m may know better.

[wvu]

The answer is precisely 4.0.0: https://redis.io/commands/module-load.

Available since 4.0.0.

Since Redis 6 is in beta, the documentation can perhaps be updated to say "since 4.0.0" if the functionality persists in version 6. If the functionality is removed, we should update for that, too.

[Green-m]

@wvu-r7 Thank you for catching that! I did not see this until yesterday. I would update it for more precise.