Spider request - proxy.php

[firefart]

Because I found another one using such a cool script: http://plugins.svn.wordpress.org/open-data-viewer-for-austria/trunk/proxy.php

It would be great to spider the repo for proxy.php and identify these scripts to get them removed or secured

[erwanlr]

Interesting :

Some weeks ago, I read an article about a website having a lot a DDoS requests done by wordpress blogs

I think this was the kind of script involved ;p

[firefart]

I saw it on several plugins in the past and this is a horrible feature...especially when you provide the output of the website. Let's hack some internal router-webinterfaces ^^

[ethicalhack3r]

Not concrete numbers but a good indication:

site:http://plugins.svn.wordpress.org/ proxy.php

Seems like you're right, quite a few! Last time I spidered the repo they blocked my IP. >.<

[erwanlr]

I've started to crawl the plugins directory

[fgeek]

Do you want to test if I crawl it faster? :)

[erwanlr]

Yeah :D (or we will both banned ;P)

[erwanlr]

There is also this one : http://plugins.svn.wordpress.org/thydzik-google-map/tags/1.5/xml-proxy.php (found with Ryan's google dork)

[firefart]

There is also this problem with open curl interfaces: http://blog.volema.com/curl-rce.html

[erwanlr]

I got bored, it takes too long xD (300k links, 0 result)

[fgeek]

I don't think looking for files named "proxy.php" is enough. Crawling script needs some logic how to detect issues like these, which is pretty easy to implement and when we are talking about checking every .php from the repo it generates a lot of traffic even if we talk about trunk so traffic limiter must be used. I can try to find out more similar issues in the near future.

[infodox]

Just an idea, and a bit silly: but can you not do a SVN checkout of the entire repository (yes, it would take time, but on a fast server?) and then scan your local copy with a CRON job to svn up it daily?

If you do, we have been working on something to do just this kind of checking source code and filenames in a repo to find timthumbs. Just need a repo to test it on :)

[erwanlr]

That was my idea long time ago, but can't remember why we choose the spider instead :p

And I still think it's a better idea than the spider :D

[firefart]

anyone knows how big the svn repo is? Are there size restrictions for plugin developers?

[ethicalhack3r]

Here is my last attempt a few months back, it only checks out the trunks and sparks a new SVN session per plugin, even then it was taking a very long time and I gave up after a day or two:

#/usr/bin/bash

plugins=( $( cat plugins.txt ) )

echo "[+] $(( ${#plugins[@]} )) total plugins"

for plugin in "${plugins[@]}"
do
  echo "${plugin}"
  svn co http://plugins.svn.wordpress.org/${plugin}/trunk/ ./${plugin}
done

plugins.txt contains the list of all plugins in the SVN repo, can be found here: https://github.com/wpscanteam/wpscan/blob/master/data/plugins_full.txt

Might be able to be improved upon though, or maybe someone has more patience than me.

[erwanlr]

wpscan.org is on one of our server right ?

If so, could we checkout the repo on it ?

[ethicalhack3r]

wpscan.org currently just points to github pages, we have the server @gbrindisi setup for the API though

[infodox]

I tried a checkout of the whole thing, they eventually killed my connection though. I have over 19k plugins downloaded for scanning :)

A plugins.svn.wordpress.org/wp-world-travel/tags/1.0.9/wp-world-travel.php svn: REPORT of '/!svn/vcc/default': Could not read chunk size: connection was closed by server (http://plugins.svn.wordpress.org)

root@CentOS-63-64-minimal:~/wordpress/plugins.svn.wordpress.org|⇒ ls | wc -l 19225

So, if someone has something for scanning all that data, I am more than happy to run it. Am working on something myself also :)

[ethicalhack3r]

Sweet! Good run! Did you checkout everything or just the trunks? Keep us updated with your research findings! :)

[infodox]

Literally did a "svn checkout http://plugins.svn.wordpress.org/" to see how far I would get before something went wrong on a server I have. Not exactly sure what I have at the moment, but about 19k dirs, seemingly with version information in there as well. Going to find something now for searching through all those files...

[erwanlr]

what about the find command to check filenames ? (find path_to_repo -name '*proxy.php')

Btw, what size is your current checkout ? (du -sh path_to_repo or du -sh if you are in the repo)

Edit:

Found those 'svn searcher' : http://sourceforge.net/projects/svn-search/ http://svnquery.tigris.org/ FishEye seems to be great, but non free : http://www.atlassian.com/software/fisheye/overview maybe there is an equivalent somewhere.

However, due to the huge number of files in this repo (and the themes one), there might be some crashes, or non responses from those tools ;p

[infodox]

Both of those commands taking a fair while to deliver output, but I estimate it to be around 80gb+. About an half hour in, only 61gb of HDD space was in use, now 142gb of space is used up, and I dont think anyone has used the box for anything else during that time. Also doing a find for "uploadify.php" while I am at it.

[erwanlr]

Huhu,that's hugeeeeeeeeeeee xD

[infodox]

root@CentOS-63-64-minimal:~/wordpress|⇒ du -h -s

122G .

"oh lord, 122gb of (vulnerabilities) eh?"

Here is the output of the "find proxy" :) https://gist.github.com/infodox/5271077

"Find Uploadify" (hello instant shell upload vulns...) https://gist.github.com/infodox/5271081

Vulnerable OpenFlashChart... More shell upload fun https://gist.github.com/infodox/5271349

I have a list of files to search for somewhere, will do a batch job later on it or something.

[erwanlr]

Awesome !

Thanks for those :)

122 Go is really huge, I didn't expect this size xD

[gbrindisi]

Wow, is 122gb definitive? I thought it would be worse.

[fgeek]

For me SVN checkout says: "Out of memory - terminating application." or timeout errors. Maybe it is better to enumerate all plugins and call checkout one by one or use Git.

[gbrindisi]

What about spidering behind proxies/tor?

[fgeek]

If I see you use Tor for something like this I would slap your face ;)

[gbrindisi]

You can't see me trough the internet! Ah :)

Anyway jumping trough proxies is still valid, and if wordpress.org is blocking based on a requests/time value we might evade the block by slowing down the spider (not ideal though).

[fgeek]

Spidering is not the problem. SVN checkout from whole plugins-repo is.

[erwanlr]

If the checkout fails, you can still do a svn up and it will resume it ;)

[firefart]

they also disabled the svn protocol :( This would speed it up instead of the "slow" http protocol. I would like to see a svn to git sync from wordpress like they do with the wordpress core code. The SVN repo is synced every 15 minutes to Github. Maybe we should open an issue for that on the official bugtracker?

[fgeek]

Yes I know svn up obvously.

[infodox]

If they were using Git the checkout would be a crapload faster (compression). Did they seriously disable SVN? I was considering resuming the checkout this evening... Also, I tried spidering it using TOR a while back with newnym.py set to every 5 minutes (they were blocking the spider) and it was ridiculously slow. I think asking nicely for them to sync the plugins and themes would be a good idea. Are they not supportive of better security for their users?

[gbrindisi]

@infodox I've mailed them this morning.

[erwanlr]

They suggested us to use https://github.com/markjaquith/WordPress-Plugin-Directory-Slurper

However, it uses the WordPress API, so if a plugin has been disabled, the script will not be able to download it :/ e.g : http://wordpress.org/extend/plugins/5gig-concerts/ http://plugins.svn.wordpress.org/5gig-concerts/

I ran the script this night, and got his : "It took 587 minutes and 40 seconds to update 34564 plugins"

Furtermore, 4323 were not downloaded because they are disabled or the zip is empty (their zips are in the zips directory)

The size of the plugins directory is 8.9G

[fgeek]

Not downloading disabled plugins is a big fail in our case. :) I could start mirroring the whole repo in Git. Let's see if I have time to set it up next week.

[erwanlr]

I've forked and updated the script : https://github.com/erwanlr/WordPress-Plugin-Directory-Slurper

When the main update fails, it try to update from the trunk

You can also run the update-from-trunk.php w/o argument :

• it will get all the plugin names from the zips directory (if there is a zip there it means that the associate plugin has not been updated from the update.php)
• and update them from their trunk
• Be aware that it could be very long (e.g, for the 4322 plugins which were not updated with update.php, it took me ~15h)

With all this, I still have 170 plugins which can not be updated because there is a special char either in the plugin name, or one of its file (like this : http://plugins.svn.wordpress.org/tagninja/trunk/ <- Free XSS in the .php :D)

[firefart]

:+1: Any idea how to download the old versions? They are provided as Zips on the download page as well. But i think there is no way for incremental updates on the older versions to download new zips or am I wrong?

[fgeek]

I don't think there is old versions of the zip-files available. Please also note that tags in SVN is not the same as the version for some reason. This was very confusing to me. So basicly if you take SVN checkout and do diff it is not always those versions, which users have installed. I haven't seen many of these scenarios yet (under five).

tagninja seems to be already removed from http://wordpress.org/extend/plugins/search.php?q=tagninja please add it to wpscan if it's not there yet.

[erwanlr]

There is old version zips, the link is in the Developers tab of the plugin :

• http://wordpress.org/extend/plugins/jetpack/developers/
• http://downloads.wordpress.org/plugin/jetpack.2.2b8.zip

I think the difference you had between versions might be caused by the way WP manage the zips througt the API, there are 2 ways of doing it :

• When a zip's version is requested, it's dynamically created by fetching the svn
• When a plugin is tagged, the zip is created and stored on the download server

With the 2nd scenario, there might be a problem when some files are updated and the plugin is retagged to and existing version, which seems to be the cases you had ;p

Edit : For tagninja, I did not find any reference of the vulnerability, and I do not have the time to fill a disclosure :x

[erwanlr]

Some details :

There are 34632 plugins in the svn repo

• 170 non dowloadable
• 1303 empty (<- :o)
• 33159 downlodable, for 9.9G

[erwanlr]

find . -name '*proxy.php' : https://gist.github.com/erwanlr/e203a38ab1d3494fba1b

[infodox]

Much cleaner than my attempt, I think I got "every version of everything ever and a load of other crap" when I ran that. Nice work :)

[erwanlr]

Closing it, as the request has been done

[firefart]

thx for the result!

[erwanlr]

NP :)

It's quite fast, so if you have another to do, don't hesitate ;p

[firefart]

i will open another issue for ideas :)

[firefart]

See Issue #161