* Discovery Date: 2015/10/19
* Public Disclosure Date: 2015/12/01
* Exploit Author: Panagiotis Vagenas
* Contact: https://twitter.com/panVagenas
* Vendor Homepage: http://usersultra.com
* Software Link: https://wordpress.org/plugins/
* Version: 1.5.50
* Tested on: WordPress 4.3.1
* Category: webapps
Description
==============================
One can perform an SQL injection attack simply by exploiting the following WP ajax actions:
1. `edit_video`
2. `delete_photo`
3. `delete_gallery`
4. `delete_video`
5. `reload_photos`
6. `edit_gallery`
7. `edit_gallery_confirm`
8. `edit_photo`
9. `edit_photo_confirm`
10. `edit_video_confirm`
11. `set_as_main_photo`
12. `sort_photo_list`
13. `sort_gallery_list`
14. `reload_videos`
POST parameters that are exploitable in each action respectively:
1. `video_id`
2. `photo_id`
3. `gal_id`
4. `video_id`
5. `gal_id`
6. `gal_id`
7. `gal_id`
8. `photo_id`
9. `photo_id`
10. `video_id`
11. `photo_id`, `gal_id`
12. `order`
13. `order`
14. `video_id`
In case #7 a user can also change the gallery name, description and visibility by setting POST parameters `gal_name`, `gal_desc` and `gal_visibility` respectively.
In case #8 `photo_id` is first casted to integer and a query to DB is performed. If results are returned then for each result a new query is performed without casting the `photo_id` to integer. So if an attacker knows a valid video id then it can perform the attack in the second query. This achievable because `<?php (int)'1 and sleep(5)' === 1; ?>
In case #9 a user can also change the photo name, description, tags and category by setting POST parameters `photo_name`, `photo_desc`, `photo_tags` and `photo_category` respectively.
In case #10 a user can also change the video name, unique id and type by setting POST parameters `video_name`, `video_unique_id` and `video_type` respectively.
Because function wpdb::get_results() and wpdb::query() are in use here, only one SQL statement can be made per request. This holds severity of the attack low.
In addition all actions are privileged so the user must have an active account in vulnerable website, in order to perform the attack.
PoC
==============================
Send a post request to `http://my.vulnerable.website.
Timeline
==============================
2015/10/29 - Vendor notified via email
2015/11/11 - Vendor notified via contact form in his website
2015/11/13 - Vendor notified via support forums at wordpress.org
2015/11/14 - Vendor responded and received report through email
Solution
==============================
No official solution yet exists.
Komentarų nėra:
Rašyti komentarą