Archives

Post navigation

This first vulnerability in the /ajax/symposium_groups_functions.php file makes use of the functionality for people to view the users of a group. It accepts a groupID(gid) which it inserts without validation into a query and then spits out the result, even if you are not authenticated.

PHP

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

// Get group members

if($_POST['action']=='get_group_members'){

$gid=$_POST['gid'];

// First clean up the table, making sure there are no user ID = 0 (do across all groups)

Because it uses multiple line, we have to do a bit more work than the other ones. We can craft an union select which fits in and uses the rest of the query without a problem like this, and dump a list of usernames and password hashes:

It reads in 2 variables from $_REQUEST, which can be either GET or POST parameters. That’s very handy. It then proceeds to stuff the size into the SELECT part of the query using plain concatenation without previous sanitization, and then uses the wordpress prepare method of passing in content to a query safely using a printf syntax, which is safe.

Because we have control over the SELECT part of the query, we can easily select out a single piece of data at a time, which is sufficient to dump the whole database as needed. Here we can pull out a password from the users table, for instance, using a very simple request, no authentication required:

This vulnerability relies on the way which profiles are shown in Symposium. It calls into the symposium_show_profile method in symposium_profile.php file, which finds out what ID to show information for like this, assuming you are authenticated:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

// Adds profile page

functionsymposium_show_profile($page)

{

global$wpdb,$current_user;

$uid='';

if(isset($_POST['from'])&amp;&amp;$_POST['from']=='small_search'){

if($_POST['uid']==''){

$search=$_POST['member_small'];

$uid=$wpdb-&gt;get_var("SELECT u.ID FROM ".$wpdb-&gt;base_prefix."users u WHERE u.display_name LIKE '".$search."%'");

Note that the last line takes the $uid variable as determined on the first block of code, and simply puts it straight into the query without any sort of input sanitation. So by creating a page with the “[symposium-profile-menu]” short-tag, we can inject into the page with a simple URL like this:

This vulnerability is actually more like 2. We can see that in this standard ajax call in /ajax/symposium_forum_functions.php file that there is a total of 4 SQL queries executed, 2 updates and 2 selects. Notice that the $_POST parameters aren’t sanitized before use, yet all but the 3rd query uses concatenation to create the SQL query, which creates SQL injection conditions if you are logged in.

A similar lack of input validation can be seen in the /ajax/symposium_profile_functions.php file in the addFriend action handling code. It takes in an ID for a friend to add and then starts putting together some SQL like this:

Analysis of add_to_page vulnerability
The first vulnerability in /ajax/symposium_ajax_functions.php in the “add_to_page” action relies on a lack of validation of the $current_user variable that is declared through global. The function allows you to append text to any arbitrary page, which can be abused for a XSS attack.

Because there is no validation of the user calling this action before this, as the $current_user variable is only just globally included at line 156, and no valididation is made in respect to it, we have a vulnerability since globally including a variable does not guarantee that it exists. Therefor you can call this while not being authenticated, and add a XSS payload to any page:

If you now load the frontpage(Which is by default page 1), you will now observe that it alerts out your cookie.

Analysis of add_new_page vulnerability
This vulnerability in /ajax/symposium_ajax_functions.php is very much like the first one. Again it’s a lack of validation of the current user. This function, rather than add content to an existing page, serves to allow an user to create a new page with some content(A shortcode specifically, but no validation is made that it is just that). This block of code might look big and scary, big in reality most of the lines are simply SQL queries.

This long bit of code will effectively take in any arbitrary text input and add a new page with said input. As there’s no validation of the current user being authenticated, leave alone being an user with appropiate privileges to do this, we can exploit this to pull off a persistent XSS by adding a new page:

Analysis of import_template_file vulnerability
The last vulnerability in /ajax/symposium_ajax_functions.php is a bit more fun, because it does not directly touch the DB in this code. Rather, it uses the symposium_update_import_snippet function to extraplote a value to insert into the database through update_option. By being a bit crafty with our request, we can once again cause a persistent XSS due to a lack of validation of the calling user, since we can ship our payload into parts of the template, many of which are used by *most* pages.

In our request, we need to add a bit of whatespace around our payload to allow for a margin of error, because the way it does the substringing isn’t that nice. This request will show how to do a simple alert, which will show on most pages on the site.

Analysis of group_menu_settings vulnerability
The group_menu_settings function in /ajax/symposium_group_functions.php allows an user to show settings for a group. The function takes a POST parameter called “uid1″, which is used for a sql query.

1

2

3

4

5

6

7

8

// Show Group Settings

if($_POST['action']=='group_menu_settings'){

global$wpdb,$current_user;

$gid=$_POST['uid1'];

$group=$wpdb->get_row($wpdb->prepare("SELECT * FROM ".$wpdb->prefix.'symposium_groups WHERE gid='.$gid));

However due to an incorrect use of wpdb->prepare, the groupID is never sanitized. Also the function does not check user credentials until line 616, and as such allows for a SQL injection through a simple POST request like this:

It first checks if the user is logged in, and then takes to mail_to POST parameter and append it to the query. But because there is no validation that the mail_to variable is in fact an integer, we can make a POST request if we have an authentication cookie, and exploit this SQL injection vulnerability:

It first checks if the user is logged in, and then takes to mail_id and recipient_id POST parameter and stitches those into 2 SQL queries using simple concatenation. However due to a lack of validation of the parameters being integers, we can exploit this:

Analysis of symposium_openchat vulnerability
The symposium_openchat function in /ajax/symposium_bar_functions.php allows for opening a chat with another user on the site. It does so by getting the chat_to POST parameter, which si expected to be an integer, and then checks if that chat already exists:

If you’re logged in and the chat does not exist, on line 572 it will then insert a new chat and select the display name from the user table, and incorrectly use the wpdb_prepare function. By rather concatenating the ID in instead of passing it as a parameter, we can now select data out of the database like this:

It checks if you’re logged in, and then takes the tid POST parameter and concatenates it into a SQL query without casting it to an integer or otherwise sanitizes it. This means we can exploit it by making a request like this:

Multiple blind injection spots in /ajax/symposium_mail_functions.php
On line 94, 101, 208, 210, 274, 276 in /ajax/symposium_mail_functions.php there is also a lack of validation of integer inputs, which allows for arbitrary query execution.