Hi
I have GVM 20.08 source edition installed and running ok and have been elaborating with different scan configs but the scan result is very unreliable in terms of identifying application running on server. I have tried scanning using the default configs but also customisations such as using Full and fast + saying yes to “Enabling web application scanning” etc.
All our servers is either Ubuntu 18.04 or Ubuntu 20.04 and other than that identical except the actual version of the application (ie the version of jira and confluence). On some server scans the application is found and is reporting the correct jira / confluence version but on some servers no application is found at all. All scans is doing some kind if findings and for example openssh is identified by scans on all servers
Is there some thing that can be tweaked so that our scan can identify the application running on server in a more reliable way ?
(what im expecting from each scan is to at least identify which version of jira or confluence that is running on server)
Server A is running a fully patched Ubuntu 18.04 and running Jira version 8.8.1
Server B is running a fully patched Ubuntu 18.04 and running Jira version 8.8.1
Both servers has the identical target + scan definitions in GVM and when running scans the reports identifies OpenSSH + Jira 8.8.1 on ServerA and just OpenSSH found on ServerB
One difference here is that ServerA has Jira started using docker container and ServerB is running Jira the traditional way on server, still the ports exposed etc is the same on both.
Really need help here to figure out why the scan is so different in its findings.
ServerA says ‘Ports (1 of 3)’ and I can see port 8080 which is Jira and in the applications tab jira is mentioned). ServerB says 'Ports (0 of 3) and I guess this is why jira is not found in application tab
When selecting the ports tab on ServerB and change filter from “apply_overrides=0 min_qod=70 first=1 rows=100 levels=hml sort-reverse=severity” to “apply_overrides=0 min_qod=70 first=1 rows=100 levels=hmlg sort-reverse=severity” ServerB shows 3 of 3 ports of which port 8080 is one of them (i just modified levels in the filter adding ‘g’)
Changing the filter as mentioned above does not make Jira become visible in the application tab on ServerB.
So, the jira port seems to be fetched by scan but excluded somehow due to the filtering. Not sure how to correct this so it becomes included in scan and can identify jira properly
So looks like at least the port scanner found the port 8080 open (hence the log report about it you’re seeing). However it might be that further requests got blocked or something else went wrong.
Do you see any log reports from e.g. “CGI Scanning Consolidation” (OID: 1.3.6.1.4.1.25623.1.0.111038) or “HTTP Server type and version” (OID: 1.3.6.1.4.1.25623.1.0.10107) which would indicate that further scans on this port where conducted. If not, either the scan might got blocked or the service died during the scan.
Did another test and edited the scan_config and changed the timeout for “Atlassian Jira Detection” (in Product detection family) to 72000 (assumed that 36000 was default) but no luck. During the same edit I also changed the global variable “Log verbosity” to debug but nothing in logs except "DEBUG: find_service1.nasl(10.2.165.8): Service on port 9010 does not answer to “GET / HTTP/1.0"” which was new and mentioned for both ServerA and ServerB
did you set the log_whole_attack option to yes in the openvas.conf configuration file? This option must be set to yes in order to log some plugin’s activity. At least you will be able to see if the plugins are being scheduled and launched.
The command openvas -s shows the current configuration. This option (enabled) can flood the log file. So, I recommend a carefully usage. Also, this is a scanner only option, and affects all scans.
I actually found out what the problem is (or rather just now noticed the first comment I got in this thread about checking the banner …sorry for not paying attention) .
I did a curl -v http://ip:8080 on both servers and serverA reports back in the header http 200 response and with info such as Set-Cookie: atlassian.xsrf … and meta name=“application-name” content=“JIRA” data-name=“jira” data-version=“8.8.1”
On ServerB jira it has an addon installed that makes / respond with http 302 and a redirect to Location: /plugins/servlet/samlsso?redirectTo=%2F and in short no other information received
Which leads me to a new question/topic, is there a way to create a custom nvt ?
I found /opt/gvm/var/lib/openvas/plugins/secpod_atlassian_jira_detect.nasl and In that script I did a test changing:
rcvRes = http_get_cache(port: port, item: dir + “/login.jsp”);
to:
rcvRes = http_get_cache(port: port, item: dir + “/login.jsp?nosso”); )
(adding this nosso in the end is a builtin within this addon to override the redirect)
On the next scan ServerB was able to locate Jira
I tried to copy that nasl script to a second script (changing name and oid within script) but when running greenbone-nvt-sync all changes was gone due to the sync and the second script was no more
This should be indeed the reason why Jira on ServerB isn’t detected. AFAIK it is expected / a wanted behavior that the scanner / the NASL HTTP functions are not following redirects automatically. Redirects needs to be handled by the VTs itself.
I have raised an internal ticket so that the Product-Detection is extended to detect all Atlassian products (seems besides Jira the plugin is also supported on Confluence, Bitbucket and Bamboo) once this plugin is installed and enabled.
This is a good hint. Unfortunately it seems that this functionality of adding ?nosso to the login URL can be disabled according to:
Meanwhile I successfully managed to create a new set of custom NVT’s. I copied the plugin files for jira, confluence and bitbucket and stored them in a subfolder plugins/private. Then in these 3 files I changed the OID, Name and then the login url added ?nosso in the end.
Then as root I issued below to trigger a cache rebuild
su - postgres -c “psql -q --pset pager=off gvmd -c “DELETE FROM meta where name = ‘nvts_feed_version’ OR name = ‘nvts_check_time’;””
Just ran a scan and it works ok so now jira is found on both ServerA and ServerB
