We don’t need NASL - OpenVAS
For those of you who are new to these things, NASL stands for Nessus Attack Scripting Language. NASL is part of the closed-source Nessus vulnerability scanner and its open-source form called OpenVAS (Open Vulnerability Assessment System).
Nessus plays big part in the hearts of many administrators, security consultants and scanning vendors. Nessus practically was the first stable and well maintained open-source security scanner until they closed the source.
So, what about NASL? My point is that we don’t need it. Recently I had to work with OpenVas and Nessus in order to automate some trivial penetration testing practices. I’ve worked with both and I got fed up with NASL. I still cannot understand why on earth we need yet another general purpose scripting language which looks like some kind of a hybrid between PHP, C and JavaScript.
Anyway, so since version 3 Nessus is closed source. Now we have OpenVAS, a 2.x fork of Nessus. The project is coming nice but still far from begin good enough for environments where stability is a must. At some point I decided to contribute since I am particularly interested in haviong a free Nessus clone with a good community behind it. As soon as I started putting down some code I realized that this is not what I want. Nessus’ code seems undeservingly complicated.
In reality I do not need Nessus neither NASL. All I need are the tests. I believe that everybody feels the same. Perhaps the whole OpenVAS project should concentrate on writing the tests and let the user choose the engine. In my case Nessus was not a good engine due to license limitations. OpenVAS was not a good fit as well because of stability reasons. I am stuck!
It occurred to me that because NASL is very close in syntax to PHP, JavaScript and C, it will be actually easy to rewrite the scripts in a more suitable language that has a better community around it. Of course everything needs to be done in an automatic fashion because I hardly doubt that anyone have the personal time to sit and rewrite boring NASL scripts, unless he is paid good money for. This is not how things work in the open-source world though.
Unfortunately, I do not have the time to start such a project although I will most certainly contribute. I hope that someone is willing to take on the challenge. Any takers?
Comments
I find myself leaning towards nmap, w3af, and metasploit for all my developments.
Nmap has a great scanning engine, and with the the lua interpreter and nmap libraries it makes a devent development environment for general discovery scripts. It has replaced Nessus for me in my development.
W3af is growing into a decent web testing tool, though it definitely has its own problems and quirks and consumes too much memory. It’s written in python, and can be easily extended. Paros is more stable, uses less memory and works better for many tasks at the moment, but the architecture is an evolutionary dead end.
Metasploit is written in ruby and has the best general network packet manipulation libraries I’ve ever worked with, and is great for all manner of packet creation and discovery tasks.
Given the new BSD license, when I build any new security tools I will strongly consider either writing them for metasploit, or borrowing some of their libraries. They have done an excellent job of taking the best in class ruby libraries and extending them to be even more useful.
Some background:
Early on Nessus’s development cycles there was an effort to make perl another test writing environment, this was ‘killed’ of due to sandbox issues, hard to contain a perl script from doing malicious things
Today:
I believe things have changed, and I agree that OpenVAS can decide to ‘fork’ from the NASL to something else, the problem though in similar fashion to what Metasploit has, the dangers of sharing and running someone else’s ‘code’ can be problematic.
Metasploit has a smaller scale problem as there aren’t hundreds of exploits written for it every month, OpenVAS on the other hand, will eventually reach that point.
Some 2 cents.
I’d love to know what you mean by “decided to contribute”, because unless it means, “decided to blog, saying I had decided to contribute, attaching myself to the project, without even one email to any of the lists”, then I haven’t seen any sign of you at all.
The whole topic of what language plugins should be written in has come up more times than I care to remember and it essentially boils down to. The moment you discount NASL, you have fans of every major language out there (and that includes me - Perl ;)) pushing their pet language. Over time we’ve learnt to accept the limitations of the language and focus on the code. As a counter point, because OpenVAS is Free Software, we’re not limited to what 3rd party tools we can call out to which means we can use the best tool for the job.
Yes, we *know* the project is raw, and yes we’d love to have more resources behind it (although did you know development is now split across 3 continents and includes half a dozen different commercial outfits) but honestly, the biggest hindrance has been a problem of tainted code licenses, something we’ve finally got to grips with I believe.
With respect to stability, if you’d care to file examples, I’m sure the team would be happy to resolve any particular issues you could report, certainly the code base has been cleaned up significantly since we started work on it.
With the greatest respect to you, whilst some tests can be replaced with “regular expressions” (and I’ll think you’ll find such tests already are), there are many that can not. I’m sure simple “version disclosure vulnerabilities” can be checked this way, but not all bugs are so shallow.
Come and talk to us on IRC some time. You might still disagree with us, but hopefully, you’ll at least get a better feel for the direction the project is taking.
It’s not just that the Nessus engine is closed source, but most of the NASL scripts that drive the nessus scanner are copyrighted as well. I can’t imagine it’s legal to code up an automated converter that will take a copyrighted NASL script and magically turn it into an open source XYZ script.
Well pdp, I have the same problem. OpenVas is still too far back and even doesn’t recognize all vulnerabilities like Nessus for example, but I dislike the NASL language too….
I think it is just a matter of time till metasploit will have a vulnerability scanner included. I’m writing my own vuln scanner in ruby at the moment - standalone by now but since it’s written in ruby it should be easy to integrate it in metasploit.
Tim, I do not hang out in IRC and I have nothing substantial to show. If I had, it would have been already posted on GNUCITIZEN.
The reason NASL is inferior to other languages such as Perl, Python, Ruby, etc, is because NASL does not have a good community behind it and as such code has to be reinvented all the time. This doesn’t mean that you cannot keep the core tests (the ones that come by default with the framework) dependency free. Perhaps they can be built upon your own libraries which you are sure that are safe.
I have no right to point fingers to any of this projects but I am only giving advice based on my experience. I believe that if someone writes a framework based on JavaScript, Java then the community will pick it up very quickly because everybody understands these two languages very very well. Well, Metasploit is the winning framework here because it is based on Ruby and there are a lot of Ruby fans. NASL is not hard to learn but it puts off a lot of people before they even start.
I am deeply impressed my the Metasploit guys and what they have done. The tool is fantastic. The framework is extremely stable and extensible. But Metasploit is not Nessus and Nessus is not Metasploit. Nessus has a good reporting framework with tones of tests. Metasploit has a good penetration testing toolkit, but no good report framework. I haven’t dig deep enough into Metasploit, so if I am wrong, don’t eat me. Nmap is also coming along with their NSE scripting language which is based on Lua. I like the idea!
All of these projects started for very different purposes and all of them are heading the same way - universalism. All of them are now developed to become the one and only framework you need for security but I hardly doubt that this will ever happen. Only time will tell. I often say that we’ve got already a universal framework. It is called OS. I believe that all of these tools should try to do more of what they already do and not what someone have already done.
hawaii67, don’t wait until you are ready. Give them the code and I am sure that they will find a way to integrate it.
Metasploit is great, indeed. The thing is: I still see lots (tons) of people talking of Ruby as “that web site programming language” - prejudice, yes. Good thing about prejudice in this case is: it keeps noise away. If you hear it and believe it without even googling it, you probably better not be around.
Put that aside, prejudice is bad when it comes to commercial adoption. Even if you’re good and you want to use it, there are cases when you don’t want it simply because you can’t sell it. Take financial market as example: if you can’t integrate it with Excel, you probably won’t sell it. Stupid as it looks, but that’s the way it works (things get a little easier when you talk about algotrading). Now, the point on this colocation: there’s an obvious concern about network security - example taken - in the financial market, but everyone uses Nessus results as benchmarks and “oh, we’re safe now”. I’ve seen security firms selling their we-check-your-network-and-make-it-safe services using “we run our software on Windows” as a kind of faster-results assurance, and what they do is topology check + nessus run + report - 8 weeks guaranteed results, US$25k.
Now, this is what I see happening to most of programmers - not the ideal, not honorable, but real life, so keep that in mind: average citizen, average world. Say you’re a great programmer, and you want to be a employee in one of these firms - you tell then about Ruby, they reply “ru-what?”, puf, bye-bye job. But you tell then you have great experience using Nessus, oh, you’re a great security professional, yes you are.
It’s as chocking as it looks, but we live a non-US reality here (Latin America). I used the financial market as an example because that’s where I am right now, and I see that most of the people in charge of IT (specially IT security) only “heard about it” - and it sells only if they heard about it. This scenery is changing, yes, but in the meantime you’ll still have lots of people away from great projects just because they can’t use it in real life. It’s really great doing things by the pleasure of doing it, but sometimes you have someone else to take care of, and money *is* motivation. Not so noble, but - again - it’s real life.
definatlly worth trying :)
Why not keep mostly everyone happy and implement the Nessus NASL language as an internal DSL (domain specific language) from ruby. This would allow backwards compat, along with the flexibility of a real programing language that has a decent security community following..
Basically, if all you want “are the tests”, then that is the definition of a script kid.
Oh wait, nevermind :-)
the only reason your comment was approved is to show that you are very, very, wrong! please check Netsecurify (this post over here as well) and then make up your mind.