What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
300.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

Nessus reports a SQL Injection Vulnerability in PRTG. Is this a real threat?

Votes:

0

Your Vote:

Up

Down

A Nessus scan returns the following vulnerability. Can you provide me with a statement that this is not an issue, or fix/change it to not be flagged by the scanner. I am sure other customers have run into this already, should be a faq. Thanks.

The following URLs seem to be vulnerable to BLIND SQL injection
techniques :

/public/checklogin.htm?loginurl=&password=&guiselect=radio+AND+1=1&username=

An attacker may exploit this flaws to bypass authentication
or to take the control of the remote database.

Solution : Modify the relevant CGIs so that they properly escape
arguments
Risk factor : High
See also : http://www.securitydocs.com/library/2651

nessus security sql vulnerability

Created on Jul 15, 2010 7:24:09 AM by  Dirk Paessler [Founder Paessler AG] (10,983) 3 5

Last change on Jul 15, 2010 7:34:50 AM by  Dirk Paessler [Founder Paessler AG] (10,983) 3 5



3 Replies

Accepted Answer

Votes:

0

Your Vote:

Up

Down

Short Answer:

PRTG does not use any SQL server for internal storage, so SQL injection is completely impossible. This Nessus test script is not very accurate and shows a false positive for PRTG.

Long Answer:

PRTG manages all account data and monitoring objects in an object-oriented, tree-like internal structure that can not be modified by URL parameters or sql statements. The structure is managed "in-memory" and is only written to the disk every time something changes (e.g the sensor tree).

The Nessus seems to create a test URL based on PRTG's login form (which has /public/login.htm as the <FORM> target) and adds a "AND 1" to it. Then it compares PRTG's output with the regular output (without "AND 1"). If this output is the same it shows an alert.

When PRTG receives the URLs

/public/checklogin.htm?loginurl=&password=&guiselect=radio+AND+1=1&username=
/public/checklogin.htm?loginurl=&password=&guiselect=radio&username=

it will always simply redirect to the login page, because the login is incorrect, so both URLs will see the same result. This is not a security threat.

We have implemented various methods to to avoid many other threats, too. E.g. against Cross-Site-Scripting attacks PRTG filters all URL parameters for script tags etc. before they are used for HTML page rendering.

Created on Jul 15, 2010 7:34:36 AM by  Dirk Paessler [Founder Paessler AG] (10,983) 3 5

Last change on Jul 15, 2010 7:37:23 AM by  Patrick Hutter [Paessler Support] (7,225) 3 3



Votes:

0

Your Vote:

Up

Down

Is this something that PRTG is working on fixing? I ran a Hipaa Compliance audit on my company and we failed do too PRTG having a CGI Genereic SQL Injection problem. We used SecurityMetrics for our test.

Created on Jan 24, 2018 6:44:53 PM by  rserbia (0) 1



Votes:

0

Your Vote:

Up

Down

Hello rserbia,

Thank you very much for your contact.

We are currently not working on this, Dirks answer above is still accurate and valid.

For any other questions or difficulties, we are happy to help.,
Sebastian

Created on Jan 25, 2018 3:01:12 PM by  Sebastian Kniege [Paessler Support]



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.