Discussing Scan Report Poisoning


A security scanner actively queries virtually any type of service to collect banners, configuration settings and even entire objects such as ssh keys.

An attacker who achieved control over a target system could poison a response of this target system so that arbitrary data is retrieved from the scanner and stored as a result element.

The Greenbone solution as such takes care not to execute such content and sanitizes it properly for example in case it is displayed in the UI. However, it is stored in the database and if a report is created, the poisoned content could be part of this report.

Tools that consume such content might have less mechanisms to properly handle content and then it might happen that malicious code is executed by or via this tool.

So, a security problem can occur on a system consuming scan reports (such as spreadsheet loading a CSV report) and itself being not properly secured, for example the system itself is not up-to-date or mis-configured - or a user ignores warnings. Another precondition is a scanned system where an attacker already gained control, which might happen because the target system exposed a vulnerability or because the attacker is an insider or the scanned system was added to the network without being detected as stranger.
In no case the actual Greenbone solution gets compromised by the attacker.

What can you do to prevent a bad situation? First of all, exactly what you planned to do by introducing the vulnerability management solution: Timely remediate identified problems. Second, what you should do since ever: apply secure configurations. Third, what you should spread the word about: if a tool like your spreadsheet warns with a dialog not to open something, then do not open. Ultimately preventing such an attack path is not possible. But you can make and keep your infrastructure resilient.

Greenbone is considering to add methods to help users preventing poisoning. Naturally this will have limitations on the one hand and impact on work-flows on the other. We prepare to address so-called CSV injections for the CSV report formats plugins as a start. We welcome further ideas and thoughts.

As a last word, please consider that content poisoning can happen in same way for many other data collection processes you are running in your environment, for example inventory builders. It is also discussed recently for other application types, like DokuWiki.


Hello Jan,

you are right, content poisoning and especial this kind of attack you descriped is difficult to secure. But it is possible and mandatory to prevent executing untrusted input. When Greenbone have a export feature to CSV file format, I expect as user, that they will do as much as possible to prevent executing attacks. But this is not happend, their is no escaping of active code / dde functions.

By the way: This seems to be the security vulnerability I reported to greenbone for a few weeks. I contact you, but nobody answers. Can I assume that Greenbone will fix this issue?



Hi Marcel,
I feel compelled to contradict your statement that we haven’t answered. As you can see from our direct conversation, we actually responded to your initial email within less than an hour. The overall communication has taken some time up until this morning when you received our final conclusion. Greenbone is serious about messages we receive indicating that there might be an issue in our technology. We analyze thoroughly, look at possible side effects and most importantly try to communicate with substance.

Transporting malicious code is not a vulnerability of the transport mechanism. Any MTA, Router, Web Service would be regarded vulnerable if we would consider transportation of malicious code a vulnerability.

That being said, I agree with you that any product/solution provider should consider whether additional measures can be applied to help users in the fight against malicious code. There are limitations and especially side effects doing this, and after all it is not addressing the roots.

Greenbone always tries to improve, and we are on the special CSV aspect - as already stated above. Telling us where we could improve further is always very much appreciated.
But also, we need to ask for your understanding. We don’t want to create a false sense of security when the root problems are elsewhere.
regards Dirk


And the first patches have already been added to gvm master https://github.com/greenbone/gvm/pull/190