Server-Side Request Forgery (SSRF) in osticket/osticket
Reported on
Sep 19th 2021
Description
The SSRF vulnerability in OSTickets detailed in CVE-2020-24881 is still unfixed, attackers can still make arbitrary requests via the server to the private network via the PDF print generator although they will not be able to exfiltrate anything other than image data.
Proof of Concept
- Create a new ticket
- Select "HTML Format" format.
- The following payload queries localhost
<figure><img src="http://localhost/index.png" data-image="ub1qobqtpn81" alt="image"></figure>
- After submitting this comment, print this ticket via PDF
- You'll receive a request from localhost in Apache logs, indicating that the server is making a request to an private IP addresses
Impact
This vulnerability is capable of internal portscans, interaction with internal webservers via GET requests, as well as information disclosure of images on the internal network
For instance if I were to host an image in the internal server containing some kind of secret.png at http://localhost:8000/secret.png Then doing this will allow me to embed the secret.png at http://localhost:8000/secret.png into the PDF, causing information disclosure.
Recommended Fix
Blacklist localhost IPs and private IP addresses when printing PDFs
Occurrences
@admin I think email in SECURITY.md does not fit the format again
@haxatron
With CVE-2020-24881 we introduced a new setting to choose wether or not you want to allow external images ("external images" meaning ones not stored in osTicket's file storage [Database by default or on the Filesystem/Amazon S3 with Plugins]). When you have the Allow External Images setting Enabled, of course it will fetch the external image as you are allowing it. However, if you Disable the Allow External Images setting you should see no request for the external image when loading the thread and printing.
So the "patch" in this case is to Disable the setting. Please Disable the Allow External Images setting (Admin Panel > Settings > Tickets > Allow External Images), retest, and let me know if you can still make a request for the image.
Cheers.
Yep. Turning it off fixes the issue. Apologies for that. When I am testing applications, I usually use the default configurations and Allow External Images was turned on by default 😅 apologies for missing that out.
@maintainer, Hi there, although Allow External Images stops the vulnerability. I still think it should at least disabled by default as users may not know that turning it on introduces the vulnerability, additionally there should be HTML filtration during PDF generation, or at least an additional option, that prevents external URLs during PDF generation even if Allow External Images is on to help further mitigate this. But that is completely up to you :)
Thanks and regards!
@haxatron
I forgot to update this and mention that we are going to disable by default.
Cheers.
Thanks! Perhaps instead of html filtration I suggested earlier, you could include a whitelist for external images too, much similar to the IFrame whitelist.
@haxatron
Here is the patch to Disable by default when installing. Please apply the below patch to a non-installed codebase, run through the installer, and make sure it's Disabled:
diff --git a/include/class.config.php b/include/class.config.php
index e4b20eb..e45ebbf 100644
--- a/include/class.config.php
+++ b/include/class.config.php
@@ -247,7 +247,7 @@ class OsticketConfig extends Config {
'max_open_tickets' => 0,
'files_req_auth' => 1,
'force_https' => '',
- 'allow_external_images' => 1,
+ 'allow_external_images' => 0,
);
function __construct($section=null) {
diff --git a/include/i18n/en_US/config.yaml b/include/i18n/en_US/config.yaml
index 7fb4765..24e2208 100644
--- a/include/i18n/en_US/config.yaml
+++ b/include/i18n/en_US/config.yaml
@@ -80,7 +80,7 @@ core:
ticket_number_format: '######'
ticket_sequence_id: 0
queue_bucket_counts: 0
- allow_external_images: 1
+ allow_external_images: 0
task_number_format: '#'
task_sequence_id: 2
log_level: 2
Cheers.
Installed from Github, edited the above files, running through the installer again, verifies that the allow_external_images option is now disabled by default.
@maintainer, thanks for fixing all the issues 🙂 , could you validate the reports?
