You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I notified you on 1.3. via e-mail to contact@inoideas.org about some SQL Injection issues in inoERP (that also affects your demo system...). I didn't received any reply and the issue seems not to be fixed, so I will repaste the content here....
I will not publish the full exploit, the affected URI is:
/includes/json/json_select.php?class_name=sys_profile_header&group_by[]=injection
note that the line numbering is slightly off
Hey,
For a university project we had to search for SQL Injection
Vulnerabilities on Open Source Software, so I had a look at your inoERP
project and found several issues (https://github.com/inoerp/inoERP). I
did not find a security contact, so please forward this message to
someone, who is responsible for that
First of all in the file inoerp/includes/json/json_select.php from line
218 to 222 you are appending the parameter $_GET['group_by'][0] to the
SQL statement without sanitizing it. This leads to a blind SQL Injection
and a full compromise of the database (including username+password)! You
have to check this parameter against a white list e.g. $class->field_a.
Note that in this case, mysql_real_escape_string() is not sufficient as
this is not a string context. The same applies for
inoerp/includes/json/json_search.php.
I've attached a proof of concept exploit that can be used to execute any
SQL command and fetch the result. For example calling "python2 sqli.py http://inoideas.org/ 'version()'" will show:
If you see some suspicious activity in the logs from 3.1.2017 0:00 to
3.1.2017 2:00 MEZ from Nordersted/Germany on your demo system, this was
actually me testing the exploit.
In addition in the file: inoerp/includes/json/json_select.php you are
unserialize user controlled data in line 71, what might lead to remote
code execution (this wasn't my task so there is no PoC, you may have a
look at https://www.alertlogic.com/blog/writing-exploits-for-exotic-bug-classes-unserialize()/
The best way to avoid such issues would be to use e.g. the json
format. If serialized objects are needed, you either have to store them
on server side or secure the integrity of the Object by using Message
Authentication Codes.
I really had just a short look on this project and did not a full audit,
but I guess there might be some more Issues :/ If you have any questions
feel free to ask
best regards, Jan Ruge
The text was updated successfully, but these errors were encountered:
Yes, it's a known issue, but unfortunately, we don't have resources ( money or time ) to fix now (at least for next 3-4 months).
You can fix all these issues, and we will incorporate it next release.
I notified you on 1.3. via e-mail to contact@inoideas.org about some SQL Injection issues in inoERP (that also affects your demo system...). I didn't received any reply and the issue seems not to be fixed, so I will repaste the content here....
I will not publish the full exploit, the affected URI is:
/includes/json/json_select.php?class_name=sys_profile_header&group_by[]=injection
note that the line numbering is slightly off
Hey,
For a university project we had to search for SQL Injection
Vulnerabilities on Open Source Software, so I had a look at your inoERP
project and found several issues (https://github.com/inoerp/inoERP). I
did not find a security contact, so please forward this message to
someone, who is responsible for that
First of all in the file inoerp/includes/json/json_select.php from line
218 to 222 you are appending the parameter $_GET['group_by'][0] to the
SQL statement without sanitizing it. This leads to a blind SQL Injection
and a full compromise of the database (including username+password)! You
have to check this parameter against a white list e.g. $class->field_a.
Note that in this case, mysql_real_escape_string() is not sufficient as
this is not a string context. The same applies for
inoerp/includes/json/json_search.php.
I've attached a proof of concept exploit that can be used to execute any
SQL command and fetch the result. For example calling "python2 sqli.py
http://inoideas.org/ 'version()'" will show:
oracle("1<2") = True
oracle("1<1") = False
mask: 0 byte: 00 current secret: 5.6.33
done
If you see some suspicious activity in the logs from 3.1.2017 0:00 to
3.1.2017 2:00 MEZ from Nordersted/Germany on your demo system, this was
actually me testing the exploit.
The request
http://host/includes/json/json_select.php?class_name=fp_forecast_line&fp_forecast_line_id[]='
will also trigger a MySql error that might be exploitable. This is
triggered in line 90 to 93 as you add $_GET[$value][0] to the SQL querry
(by spliting the querey on ',' will not avoid the issue). In general
you should use mysql_real_escape_string() on every user controlled
string added to a mysql statement or cast the parameter explicitly to an
integer. If you need more Information on SQL Injection prevention, you
may have a look at:
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
In addition in the file: inoerp/includes/json/json_select.php you are
unserialize user controlled data in line 71, what might lead to remote
code execution (this wasn't my task so there is no PoC, you may have a
look at
https://www.alertlogic.com/blog/writing-exploits-for-exotic-bug-classes-unserialize()/
The best way to avoid such issues would be to use e.g. the json
format. If serialized objects are needed, you either have to store them
on server side or secure the integrity of the Object by using Message
Authentication Codes.
I really had just a short look on this project and did not a full audit,
but I guess there might be some more Issues :/ If you have any questions
feel free to ask
best regards, Jan Ruge
The text was updated successfully, but these errors were encountered: