Create wordpress_cp_calendar_sqli.rb scanner

[brandonprry]

This module will scan for vulnerable instances of CP Multi-View Calendar v1.1.4 (and prior) for Wordpress by exploiting an unauthenticated UNION-based SQL injection.

http://www.exploit-db.com/exploits/36243/

Quick run:

msf auxiliary(wordpress_cp_calendar_sqli) > show options

Module options (auxiliary/scanner/http/wordpress_cp_calendar_sqli):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   Proxies                     no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOSTS     172.31.16.49     yes       The target address range or CIDR identifier
   RPORT      80               yes       The target port
   TARGETURI  /wordpress/      yes       Target URI of the Wordpress instance
   THREADS    1                yes       The number of concurrent threads
   VHOST                       no        HTTP server virtual host

msf auxiliary(wordpress_cp_calendar_sqli) > run

[+] 172.31.16.49:80 - Vulnerable to unauthenticated SQL injection within CP Multi-View Calendar 1.1.4 for Wordpress
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(wordpress_cp_calendar_sqli) > 

Passes msftidy:

$ tools/msftidy.rb modules/auxiliary/scanner/http/wordpress_cp_calendar_sqli.rb 
$

Thanks!

[espreto]

How is wordpress, can use the Msf::HTTP::Wordpress.

[brandonprry]

Not sure what this would buy me, don't need fingerprinting or authentication... Can certainly add if there is a benefit though.

[firefart]

@brandonprry jeah there is no benefit in this module when using the wordpress mixin. But you could include it and write a check method calling check_plugin_version_from_readme (https://github.com/rapid7/metasploit-framework/blob/master/lib/msf/http/wordpress/version.rb#L50). But as this module only checks for the SQLI without exploiting it, the main method already acts as a "check method".

[brandonprry]

It technically does exploit the vuln in order to check the validity of the vuln :)

It also isn't a wordpress vuln per se, just a plugin for wordpress, the version of wordpress itself doesn't matter.

In any case, I agree, the scanner is essentially its own check method.

[firefart]

check_plugin_version_from_readme checks the plugins readme and extracts the version number (not the version from wordpress itself). So if you call it with check_plugin_version_from_readme('cp-multi-view-calendar', fixed_in_version) it will say vulnerable or not only determined by the plugins version

[brandonprry]

Oh, I see. I misunderstood.

[espreto]

@firefart is the most suitable for the recommendations. \o

[firefart]

[ 'WPVDB', '7650' ]

https://wpvulndb.com/vulnerabilities/7650

[firefart]

sorry wrong vuln, will create a new one for this

[firefart]

Please use wpvulndbid 7910

https://wpvulndb.com/vulnerabilities/7910

[firefart]

works for me:

msf auxiliary(wordpress_cp_calendar_sqli) > run

[+] 10.211.55.4:80 - Vulnerable to unauthenticated SQL injection within CP Multi-View Calendar 1.1.4 for Wordpress
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

can you please add the additional reference @brandonprry ?

[brandonprry]

Yes, doing that now.

[firefart]

thx @brandonprry !