5

Given a setup where we have nginx sat in a DMZ serving static content, forwarding (REST/WS) requests through a firewall to tomcat running on a server where other applications are also running:

YOU <> [FW:443] <> (NGINX) <> [FW:8443] <> (TOMCAT)
                                           ( APP1 )
                                           ( APP2 )
                                           (  DB  )

Can I focus on just the nginx & tomcat applications in terms of patching CVEs/vulnerable dependencies, or must I ensure that all other applications are as 'CVE-free' as possible.

I believe this is different to this question about whether applications behind a public firewall need to be patched.

mkst
  • 151
  • 2
  • 6
    Can you explain why you believe that this question is different than the linked one? The questions themselves seem fairly similar, and especially the answers (can you trust everyone in the organization? + should an attacker that breached into the internal network really be given full access to everything?) seem to apply to your question as well. It would help us give relevant answers if you could explain why these answers don't apply to your question. – tim Jan 05 '20 at 16:02
  • 1
    You could look at all the threats using a risk matrix. – Alex Probert Jan 06 '20 at 12:34
  • @tim, fair question. These apps are running in a (externally managed) datacenter, with a bastion host to get to them from our office network. If you've got that far, you probably have enough access to the applications without needing to exploit some buffer overflow vulnerability etc. I guess I'm asking whether applications behind multiple firewalls need protection from the outside, or just the 'accessible' ones. – mkst Jan 06 '20 at 14:58
  • We usually do "security in depth". No matter how much you try to secure a part of the system, that part should be assumed to be vulnerable. In case nginx fails to validate some user input, it's up to your back-end to deal with that problem. Something will get through and it's always better to secure every layer you can. I'm not gonna go into cost-effectiveness though, leaving that to the more knowledgeable. If someone manages to get a foothold in app1 and you only secured Tomcat, attackers in app1 can access app2 and your DB. – ChocolateOverflow Jun 05 '20 at 08:18

3 Answers3

1

Prioritize fixing vulnerabilities based on whether they are exploitable remotely [at least theoretically]. Prioritizing 'front facing' components is not the right approach since there could be serious vulnerabilities on components behind the firewall which could be exploited remotely. For example an XML parser you are using behind the firewall may have a known XXE issue. Firewall may do nothing to prevent it unless it is a WAF and have a specific rule to block that. With your current prioritization you would ignore this vulnerability and it would result in the application being remotely exploitable.

hax
  • 3,951
  • 2
  • 17
  • 35
  • 1
    So assumption could be that we have an (XML parser) vulnerability in APP1, for it to be exploited a user would have to craft some (XML) payload that is sent to Tomcat (which has been patched, so is not vulnerable to this particular attack), serialized/deserialized into some other message, published to, and consumed by APP1 where APP1 then does something naughty like executing some code. Right? – mkst Jan 06 '20 at 15:07
  • Yes. Something like that. XXE was just an example. It could be any such vulnerability which affects the second order components. – hax Jan 06 '20 at 15:09
  • Ideally your risk prioritization should follow a scoring mechanism, like CVSS scores. It also provides the ability to incorporate environmental factors and modify the priority to b used for your env. – hax Jan 06 '20 at 15:11
1

All aspects of your stack should be patched.

Even if App1, App2, and DB do not have direct access to the internet it might be possible to attack them indirectly. For example, if App1 is used for authentication and it has a CVE for a timing attack ... having Tomcat, 2x FW, and Nginx in front of it wont really mitigate the timing attack.

Alternatively, I might be able to pass in user data that Tomcat handles with no problem, but one of your other apps is written in nodejs or python and the string I sent contains escape sequences that could potentially do something nasty.

You should also consider your risk profile. For example, if you are vulnerable to a timing attack an external entity may be able to brute force a list of valid usernames. If this is a fandom wiki this may be trivial to non-issue ... on the other hand if this is an AshleyMadison clone a list of your users being leaked could be a very very big problem.

TLDR: yes, you should pay attention to all relevant CVEs and patch any and all that you can, and attempt to mitigate ones that you cant patch in accordance with your risk profile.

CaffeineAddiction
  • 7,771
  • 2
  • 24
  • 42
0

Can I focus on just the nginx & tomcat applications in terms of patching CVEs/vulnerable dependencies, or must I ensure that all other applications are as 'CVE-free' as possible.

You must ensure that all applications shall not only be 'CVE-free' but has reasonable security based/relevant configurations associated to it.

please consider the risk of the web application being vulnerable which is hosted on tomcat-nginx setup. If the application is vulnerable then attacker may get a hold of machine as user of same privilege used to run the application. If other application is exploitable or configuration is week and it is accessible by this hosted application's user, it may be used to control stealth factor to make the APT(advanced persistence threat) or elevate privileges. Prioritizing fixes is one note worthy point by @haxx. I request you to consider doing a through risk assessment again.

Arpit Rohela
  • 573
  • 2
  • 12
  • How do you ensure that applications are vulnerability free? Not even trillion dollar companies like Apple can make applications without vulnerabilities. – user Mar 01 '21 at 20:18