0

We are running vulnerability scans on our systems. I can see a few XSS vulnerabilities being reported, such as CVE-2020-14173. Let me quote:

The file upload feature in Atlassian Jira Server and Data Center in affected versions allows remote attackers to inject arbitrary HTML or JavaScript via a cross site scripting (XSS) vulnerability. The affected versions are before version 8.5.4, from version 8.6.0 before 8.6.2, and from version 8.7.0 before 8.7.1.

If this is a internal (not exposed to the Internet) system could I safely assume that the severity for such vulnerability could be decreased? I mean, if a bad actor has already gained an initial foothold, I could imagine that he would use other techniques to escalate privileges.

Are my assumptions valid?

schroeder
  • 123,438
  • 55
  • 284
  • 319
cyzczy
  • 1,518
  • 5
  • 21
  • 34
  • *"... not exposed to the Internet ..."* - maybe not directly. But it is pretty common that the same browser is used to access internet and intranet. In this case cross-site attacks like reflected XSS or CSRF can be used to attack intranet application by simple visiting a malicious site on the internet. – Steffen Ullrich Dec 09 '20 at 09:29
  • But for an reflected XSS attack to work the application must take some input from an HTTP request and embed that input into the immediate response in an unsafe way. So the attacker would have to know the exact pramaters to pass via the HTTP request. How would one guess information like the fqdn to be used in the url ? Regarding CSRF, that would have to mean that there's a CSRF vulnerability as well, but there's none AFAIAC. Or am I wrrong ? Please let me know. Thank you. – cyzczy Dec 09 '20 at 09:42
  • 1
    *"How would one guess information like the fqdn to be used in the url ..."* - simply guessing often helps, i.e. using things like jira.example.com. Also, jira and confluence leak the HTTP referer by default when linking to external sites, so these information might also be find in local server log files of somebody who reported a bug or similar to the vendor and included a description in their own website. – Steffen Ullrich Dec 09 '20 at 09:48
  • Thank you @SteffenUllrich Please allow me to ask you this. Could one then use such criteria at least to prioritize vulnerabilities ? I mean if I get a report with ~+2k vulnerabilities I somehow need to address them (most likely not all at once). – cyzczy Dec 09 '20 at 10:23
  • 1
    Of course the information that the site is not reachable directly but only indirectly should be taken into account when evaluating the concrete risk - which is then used to prioritize vulnerabilities. But just this fact alone is irrelevant. Instead the related mitigating factors need to be evaluated (i.e. target hostname easily available to attacker or not, maybe sanitizing of cross-site access within internal proxy etc) on how much they actually reduce the risk. – Steffen Ullrich Dec 09 '20 at 10:31

1 Answers1

0

Well, having a service internal facing only does limit the scope of who can abuse said vulnerability. (It goes from the whole world to a quite limited subset of users with acces to your intranet)

So just like if an exploit requires a valid admin login or not impacts its severity, so does this.

But you must also consider that xss are initiated from anywhere, so unless you got dedicated tools your browser can become a relay.

But remember that gaining access to your intranet is often easier than you think (it takes 1 compromised device after all), so it’s still the best idea to patch ASAP.

LvB
  • 8,217
  • 1
  • 26
  • 43