Open stephanie0x00 opened 2 months ago
See the branch fix/disappearing-ports
for an integration test confirming the bug. It is due to the origin.id being the unique identifier on which we apply the "dereferencing oois that were not found again". But the origin.id only uses the source
field (input_ooi) and the method
field, but this is only the normalizer_id
. As a consequence, the fact that both tcp and udp ports are found by kat_nmap_normalize
, we delete all the tcp ports after running the udp scan. Hence we have to add the boefje_id to the origin_id and perform a proper migration.
Tldr; The trigger for this bug is the nmap udp scan. If nmap scans already exists and the udp scans complete, the first data is discarded. During the standup it was mentioned that this was due to insufficient garbage collection.
Describe the bug There appears to be a bug in the parsing or visualisation of nmap data for TCP data. When scanning against mispo.es I observe the following data:
When enabling the Nmap TCP boefje I observe that at first I get a finding for port 3306 as expected. However after waiting half an hour or so, this finding disappears from the finding list as shown in the screenshots below.
12 findings observed at: 16:45:
9 findings observed at 17:15:
To Reproduce Steps to reproduce the behavior:
Expected behavior A finding for the presence of port 3306.
OpenKAT version commit e511c482e0a4eae8842e459e87ea401498fc01b6 (HEAD -> main, origin/main, origin/HEAD)
Raw files Output of raw files are shown below:
Raw files for the Open-Database-Port finding: