Code Injection in GitHub repository froxlor/froxlor prior to 2.0.10.
Improper Input Validation in GitHub repository froxlor/froxlor prior to 2.1.0-beta1.
Froxlor before 0.9.33.2 with the default configuration/setup might allow remote attackers to obtain the database password by reading /logs/sql-error.log.
Authentication Bypass by Primary Weakness in GitHub repository froxlor/froxlor prior to 2.0.13.
Code Injection in GitHub repository froxlor/froxlor prior to 2.0.11.
Unrestricted Upload of File with Dangerous Type in GitHub repository froxlor/froxlor prior to 2.0.14.
An issue was discovered in Froxlor before 0.10.14. Remote attackers with access to the installation routine could have executed arbitrary code via the database configuration options that were passed unescaped to exec, because of backupExistingDatabase in install/lib/class.FroxlorInstall.php.
Command Injection in GitHub repository froxlor/froxlor prior to 2.0.8.
Cross-Site Request Forgery (CSRF) in GitHub repository froxlor/froxlor prior to 2.0.11.
Dear Sirs and Madams,
I would like to report a business logic error vulnerability that I discovered during my recent penetration test on Froxlor.
Specifically, I identified an issue where it was possible to submit the registration form with the essential fields, such as the username and password, left intentionally blank. This inadvertent omission allowed for a bypass of the mandatory field requirements established by the system.
The surname, family name AND company name all of them can be left blank.
I believe addressing this vulnerability is crucial to ensure the security and integrity of the Froxlor platform.
Thank you for your attention to this matter.
This action served as a means to bypass the mandatory field requirements.
Lets see (please have a look at the Video -> attachment).
----------------
as you can see i was able to let the username and second name blank.
https://user-images.githubusercontent.com/80028768/289675319-81ae8ebe-1308-4ee3-bedb-43cdc40da474.mp4
Lets see again.
Only the company name is set.
Thank you for your time
!Froxlor 2 !Froxlor 1
frox 0.7.16 and 0.7.17 does not properly parse certain Deny ACLs, which might allow attackers to bypass intended restrictions and access blocked hosts.
Froxlor through 0.9.39.5 has Incorrect Access Control for tickets not owned by the current user.
Weak Password Requirements in GitHub repository froxlor/froxlor prior to 2.0.10.
Allocation of Resources Without Limits or Throttling in GitHub repository froxlor/froxlor prior to 2.0.16.
frox 0.7.18, when running setuid root, does not properly drop privileges when reading a configuration file, which allows local users to read portions of arbitrary files via the -f command line option.
Froxlor version <= 0.9.39.5 contains a PHP Object Injection vulnerability in Domain name form that can result in Possible information disclosure and remote code execution. This attack appear to be exploitable via Passing malicious PHP objection in $POST['sslipandport']. This vulnerability appears to have been fixed in after commit c1e62e6.
Path Traversal: '\..\filename' in GitHub repository froxlor/froxlor prior to 2.0.0.
Cross-Site Request Forgery (CSRF) in GitHub repository froxlor/froxlor prior to 0.10.38.
Improper Authorization in GitHub repository froxlor/froxlor prior to 2.0.0-beta1.
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') in froxlor/froxlor prior to 2.0.10.
An issue was discovered in Froxlor before 0.10.14. It created files with static names in /tmp during installation if the installation directory was not writable. This allowed local attackers to cause DoS or disclose information out of the config files, because of createUserdataConf in install/lib/class.FroxlorInstall.php.
Froxlor through 0.10.22 does not perform validation on user input passed in the customermail GET parameter. The value of this parameter is reflected in the login webpage, allowing the injection of arbitrary HTML tags.
Summary An HTML Injection vulnerability in the customer account portal allows an attacker to inject malicious HTML payloads in the email section. This can lead to phishing attacks, credential theft, and reputational damage by redirecting users to malicious external websites. The vulnerability has a medium severity, as it can be exploited through user input without authentication.
Observation It is observed that in the portal of the customer account, there is a functionality in the email section to create an email address that accepts user input. By intercepting the request and modifying the "domain" field with an HTML injection payload containing an anchor tag, the injected payload is reflected on an error page. When clicked, it redirects users to an external website, confirming the presence of an HTML Injection vulnerability.
PoC 1. Navigate to the Email section in the Customer Account Portal and create a new email address.
2. Enter any garbage value in the required field and intercept the request using Burp Suite.
3. Locate the "domain" field in the intercepted request and replace its value with the following HTML Injection payload:
<a href="https://www.google.com">CLiCK</a>
4. Forward the modified request and observe that the injected payload is reflected on an error page.
5. Click on the displayed "CLiCK" link to verify that it redirects to https://www.google.com, confirming the presence of HTML Injection.))
Impact An attacker can exploit this HTML Injection vulnerability to manipulate the portal’s content, conduct phishing attacks, deface the application, or trick users into clicking malicious links. This can lead to credential theft, malware distribution, reputational damage, and potential compliance violations. The users of the customer account portal are impacted by this vulnerability. Specifically, any user who interacts with the email section of the portal may be tricked into clicking malicious links, leading to potential phishing attacks, credential theft, and exposure to other malicious activities. The organization hosting the portal could also be impacted by reputational damage and compliance violations.
Recommendation It is recommended to implement proper input validation and output encoding to prevent HTML Injection. The application should sanitize user input by stripping or escaping HTML tags before rendering it on the page.
An issue was discovered in Froxlor through 0.10.15. The installer wrote configuration parameters including passwords into files in /tmp, setting proper permissions only after writing the sensitive data. A local attacker could have disclosed the information if he read the file at the right time, because of createUserdataConf in install/lib/class.FroxlorInstall.php.
Business Logic Errors in GitHub repository froxlor/froxlor prior to 2.0.10.
Argument Injection in GitHub repository froxlor/froxlor prior to 2.0.0-beta1.
Cross-site Scripting (XSS) - Stored in GitHub repository froxlor/froxlor prior to 2.0.22.
Multiple cross-site scripting (XSS) vulnerabilities in the Customer Add module of Foxlor v0.10.16 allows attackers to execute arbitrary web scripts or HTML via a crafted payload entered into the name, firstname, or username input fields.
Unchecked Error Condition in GitHub repository froxlor/froxlor prior to 2.0.10.
Cross-site Scripting (XSS) - Stored in GitHub repository froxlor/froxlor prior to 2.1.0-dev1.