I am trying to make our workflow smoother when processing output from tools like nessus or nmap.
I have an issue for example when I created already a node where I have my hosts and I already linked some manual findings to it. After that I import Nessus findings. Even though I import them to the same node Dradis will make a new node even though a node with the same name exists already. Could you build in a check, that verifies if a node with the name already exists and if yes associate the issues with the existing one?
The problem is probably the ‘parent node’ setting. Plugins look for a ‘parent node’ setting (“plugin.nessus” by default) and will only add nodes/notes under it. This is to avoid inadvertently modifying your project structure.
So for example to have all your hosts created under a ‘hosts’ node
You’d need to change the ‘nessus:parent_node’ setting to ‘hosts’, and manually create your hosts under “hosts”. Nessus will look for any existing hosts and only create new nodes if none are found.
Happy to help talking of bugs there’s a minor one with the export results > save and restore project information menu. If neither package nor template are selected and the export button is clicked it will get grumpy
Any ETA on the bug fix for the services table clash? For now I think I’ll use Metasploit as the hub and main source of information, so I’ll use the services table generated from there thanks.
Also happy to report OpenVAS XML v8 import is working great. Plugin is listed as v6 and v7. V 9 released, but not yet in Kali…
Thanks for passing this on! I’ll add this to the backlog to look into in the future.
Have you tried importing any v9 files yet? We rely on users like you to help us stay up to date with the latest file formats and changes for the different plugins. Your assistance is always greatly appreciated! If there are any changes to the XML formatting in OpenVAS v9, we can make the necessary changes to our plugin to get things importing as expected. If you have any problems with the v9 format, let me know and we’ll collect a sample file from you and get digging!
Awesome, thanks for the bug fix, but I’ve frozen my build for now through my OSCP course, and certainly won’t be able to update to OpenVAS 9 at this stage as it’s not yet in the Kali build. Something for my own list to do at some time!
Happy to report that Dradis is working perfectly now (other than the issues described), and have a good workflow.
Some thoughts for the improvement wishlist:
With the way the UI is designed it is ever so easy to press the wrong delete button! I was intending to delete a note for a node and deleted the whole node. Ooops. Gone. Just like that. Thank goodness for backups and I was super lucky and had another tab open with the deleted notes data within. But no trash can in CE… Maybe a minor UI change somehow would help here? Or add a trash can and or scheduled backups (project zip export)
Often a host is penetrated with multiple vulnerabilities for more than 1 issue. When generating the HTML report the template retains the phases for each node, however it may be that one issue allows for enumeration, whilst the next issue allows for exploitation. Is this a pro feature to be able to merge issues when generating a report?
In the report template (Which I’ve revised to suite my own needs) the references section doesn’t make hyperlinks of URLs. Any idea how I could amend the template to resolve this?
Often a good starting point to penetrate a host is to review all the evidence of issues collected by tools. However when producing a pentest report it’s necessary to delete the vast majority of these (it’s not a vuln report after all), retaining only those issues that allowed penetration. But deleting lots of notes or evidence items one by one under a node is painful. Would be great if these could be selected by checkbox for deletion.
Similarly when deleting evidence from a node it would be wonderful to have an option to delete the primary issue in the DB, as long as there are no other nodes associate with it. As it is I have masses of redundant issues now and viewing these on the summary page is now distorted by including those issues not otherwise used in a penetration.
Did I tell you Nikto 2.1.6 XML scans are also importing perfectly!?
Screenshots in CE would be wonderful. I have a cludgy workaround, but nevertheless a sorely missed feature…
I have tagged all my issues according to severity, but I can’t filter them based on the tag. For example I filter on the word critical (a tag name) and if a record contains the word it will appears even though the tag may not be set to critical.
The killer feature to come, or is it in Pro? Global search. You know there’s a command you’ve documented somewhere, but can’t recall which node it’s under…!
Overall It’s been a bit of a challenge to get working on Kali, but I’m now delighted to have put the time and effort in - working well for me. Am becoming quite a Dradis fan!
@Kalaratri What version of Dradis are you currently running? The footer of the right-hand sidebar is the best place to check. I ask because several of the feature requests have already been implemented in the latest version and I think you’ll enjoy them
A Oh wow, sounds like half my wish list has already come true I’m currently on v3.1.0.rc2. What’s the latest?
Could you explain how I can approach the update? With minimal risk of breaking things?
Before I create a ticket for item 3 I’ll check to see if the same behaiour is happening with the supplied OSCP 0.3 template. Maybe it was my own customization to the template that broke it!
Re item 5. It would be great to be able to delete all issues that aren’t referenced in any node’s evidence, but this would have to wait until the end of the pen test process for all hosts. I’d much prefer a workflow that allows mass vulnerability scanning of all hosts, then work through the hosts one by one, deleting evidence that doesn’t lead to the penetration, whilst deleting the master issue if it’s not referenced by another node. This way the pentester can use the summary page to iteratively work through the most critical issues first. However there may be a more elegant workflow that I haven’t considered? How would you envisage the workflow?
I’d promised myself to freeze my Dradis build through my OSCP Labs, but the global search alone is making me reconsider!
I’ll gladly let you know how I get on.
Great stuff keeping the development so fresh. I’ll have to Try Harder to think up some better feature requests!
You can delete the Issue from the All Issues/Summary page. In your case, Issues aren’t referenced by any Hosts (e.g. don’t have any Evidence associated with them) would have a 0 in the Affected column. As far as the overall workflow, that’s going to depend on you and your team. If a sticking point is automatically deleting Issues that are no longer referenced by any Hosts (e.g. don’t have any Evidence associated with them), you could look at scripting this instead?