OpenVAS Installation (Debian 7 / LinuxMint 17)

(UPDATE 2016-01-20: you can find an updated version of this post for OpenVAS 8 here)

At last, a useful post on this blog ;)

For some time now, I use OpenVAS to check my clients' network and infrastructure. OpenVAS is a libre fork of Nessus, a well known vulnerability scanner. Like most powerful products, it can be a nightmare to properly install and configure. Many resources are available about this on the Internet, but none of them worked fully for my usage. So here is my OpenVAS install procedure. I hope it may be useful for others.

This procedure worked on Debian 7 and Linux Mint 17 (it should work on other distro/versions of your favorite OS), with the following versions of OpenVAS components, built from source code:

1. openvas-libraries-7.0.6
2. openvas-scanner-4.0.5
3. openvas-manager-5.0.6
4. greenbone-security-assistant-5.0.4
5. openvas-cli-1.3.1
6. And add some optional but useful stuff
7. Enjoy!

1 - Build & Install OpenVAS Libraries

sudo apt-get install pkg-config libssh-dev libgnutls-dev libglib2.0-dev libpcap-dev libgpgme11-dev uuid-dev bison libksba-dev

sudo apt-get install doxygen

sudo apt-get install xmltoman

sudo apt-get install sqlfairy

sudo apt-get install cmake

sudo apt-get install flex

tar xzf openvas-libraries-7.0.6.tar.gz

cd openvas-libraries-7.0.6

mkdir build

cd build

cmake ..

make

make doc

sudo make install

make rebuild_cache

sudo ldconfig

2 - Build & Install OpenVAS Scanner

tar xzf openvas-scanner-4.0.5.tar.gz

cd openvas-scanner-4.0.5

mkdir build

cd build

cmake ..

make

make doc

sudo make install

make rebuild_cache

sudo openvas-mkcert

sudo openvas-nvt-sync

# launch the scanner:

sudo openvassd

3 - Build & Install OpenVAS Manager

sudo apt-get install sqlite3 libsqlite3-dev xsltproc libgd-perl

tar xzf openvas-manager-5.0.6.tar.gz

cd openvas-manager-5.0.6

mkdir build

cd build

cmake ..

make

make doc

sudo make install

make rebuild_cache

# Generate key/cert 

sudo openvas-mkcert-client

# After having answered to the questions, the necessary stuff will be created in a /tmp/ directory, for instance: /tmp/openvas-mkcert-client.19926. cd in this directory and:

cp key_om.pem /usr/local/var/lib/openvas/private/CA/clientkey.pem

cp cert_om.pem /usr/local/var/lib/openvas/CA/clientcert.pem

sudo openvas-scapdata-sync

sudo openvas-certdata-sync

sudo openvasmd --rebuild

# Create an administrator user for OpenVAS

sudo openvasmd --create-user=<yourlogin>

# A message like this should be shown: User created with password 'XXXX'.

# Store this passwd in a safe place.

# Import/Update IANA Services Names

wget http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

sudo openvas-portnames-update service-names-port-numbers.xml

rm service-names-port-numbers.xml

4 - Build & Install the Greenbone Web UI

tar xzf greenbone-security-assistant-5.0.4.tar.gz

cd greenbone-security-assistant-5.0.4

sudo apt-get install libxml2-dev libxslt1-dev libmicrohttpd-dev 

mkdir build

cd build

cmake ..

make

make doc

sudo make install

make rebuild_cache

# Start the Web server

sudo gsad --listen=127.0.0.1 -p 9392

5 - Build & Install the OpenVAS CLI

tar xzf openvas-cli-1.3.1.tar.gz

cd openvas-cli-1.3.1

mkdir build

cd build

cmake ..

make

make doc

sudo make install

make rebuild_cache

6 - Add some useful tools

OpenVAS is not an isolated product, it's more useful with some other tools, without any necessary configuration, they just have to be accessible in the standard PATH:

apt-get install wapiti

apt-get install nikto

apt-get install nmap

# Download Arachni

cd /opt (or wherever you want)

tar arachni-1.0.5-0.5.6-linux-x86_64.tar.gz

ln -s /path/to/arachni-1.0.5-0.5.6/bin/* /usr/local/bin/

# Download DIRB

tar xzf dirb222.tar.gz

cd dirb222

sudo apt-get install libcurl4-gnutls-dev

./configure

make

sudo make install

6 - Enjoy!

Now, point you preferred browser to https://localhost:9392 (tell it to accept the "non-trusted" TLS certificate), follow the instruction & help in the Web UI, and kill your target servers, or the machine running OpenVAS, or most probably both ;)

Oh, to access the Web UI, you will need the login/passwd generated on step 3 (OpenVAS Manager install).

Comments welcome!

(UPDATE 2016-01-20: you can find an updated version of this post for OpenVAS 8 here)

Book review: Android 4 Fondements Internes

For once some shameful advertising, and a post in French ;)
Short translation: this book is an excellent description of the internal mechanisms of the Android OS.

Android 4 Fondements Internes, Benjamin Zores, Editions Diamond, 2014.

Je ne suis pas un grand spécialiste du fonctionnement interne d'Android, mais la lecture de cet ouvrage m'a apporté beaucoup, en tant que spécialiste en sécurité.
Même si la sécurité n'est pas ici le sujet principal, une telle mine d'information, si rare en français, est des plus appréciables pour comprendre la mécanique interne d'Android.

350 pages ne peuvent suffire à couvrir exhaustivement tous les aspects d'un OS comme Android, mais cet ouvrage donne les pistes pour démarrer, et continuer par soi-même :

- Description de l'architecture de l'OS.
- Récupération et compilation de l'AOSP, personalisation.
- Déploiment d'une version minimale sur une cible.
- Ajout des extensions nécessaires à un systèmes fonctionnel (affichage 2D/3D, Audio, Multimedia, Photo/Camera, interfaces réseaux, clavier).
- Moult références pour creuser plus avant.

Un ouvrage quasi-indispensable à tout développeur, testeur, ou simplement curieux, voire même vile chef de projet ;) désirant comprendre les bases sous-jacentes d'Android.

A consommer sans modération ici pour la modique somme de 39€

Hell Insurance!

Yesterday, having forgotten my password, I had to contact my health insurance company to get a new one, to connect on their web site.

When I read their reply this morning, I remembered why my brain had censored this password:

The ID (or login) is my social security number.

The password is my account number, given by this company, and written on EVERY documents and cards they issue!
(and probably transmitted to many other organizations, doctors, etc.)

Or course, once connected on their web site, there's no way to change your password!
This site is "read only", it is only listing past reimbursements (dates, amounts, and bank account numbers). But this is still health related information.

How is this possible in 2014?

This world is more and more like a kind of hell.

BYOD: Bring Your Own Diskettes

One of the latest nightmares of Infosec practitioners, BYOD (Bring Your Own Device/Disaster/Doom/Death... your choice), is not that new after all.

For me, it all started in about 1992, the first job of my career, software engineer in a very small video game company.
We were less than 10 people working there, none of us permanent employee. Even the CEO was working part-time while pursuing his studies.
So all the scarce budget we had was spent in hardware and software licenses for our development work.

And some floppy disks for backups, but not enough. Most of millennial people don't remember this kind of storage media, and how the could be short-lived.

So my colleagues and myself were bringing our personal floppy disks to backup our daily work/code/images/soundtracks.

I remember one day, when at last we had corporate floppy disks owned by the company, and even some Syquest cartridges (Wow! 40 MEGA Bytes of storage, beware not to let it fall on the ground, it's rather fragile!), most of my colleagues still used their own floppy disks.
I told them they were taking an unnecessary risk: if their corporate machine's hard drive failed, and they needed the floppy backup and it also failed, so all their files belonging to the company were lost, who would be responsible?
There were also some data leak issue: were they certain the floppies they kept at home were safe, there? Did they bring with them when leaving for a weekend or holidays? Even in this pre-internet & mobile era, "data at rest" was already a fiction.

Sure, those old floppy disks or Syquest cartridges or even hard drives were passive storage, compared to nowadays mobile devices (even USB things), and the mix between personal and professional use was far less a problem: floppies were cheap, so having some for pro stuff and some for perso stuff was not a big deal.

But the responsibilities were already a serious issue.

Mobile Device Management systems, multi-user (or at least multi-profile) mobile OSs or other tools would be of help.
And of course policies: simple, clear, enforceable and yielding users engagement.

It's rather disturbing to see our so modern high tech industry is still stuck with those issues of another century.

NSA & Snowden & The Rest Of The World: My Opinion

Happy New Year to all!

I didn't post anything on this blog for a long time. After much reflection, I think it's time for me to comment about the great Infosec event of 2013: the NSA/Snowden scandal.

I didn't post nor comment on this case yet. Not for lack of interest, but many people more skilled and informed than me commented on these revelations. Moreover I found it better to wait for the dust to settle. But it won't settle anytime soon it seems.

So, several months after the maelstrom began, I have some remarks I hope useful:

1 - The NSA, like many intelligence agencies, in the US or elsewhere, is spying massively. Isn't it their job?
  The main problem, here, is that they're doing whatever they can to escape democratic control, to the point the US Congress had to be briefed by external experts like Bruce Schneier.
  As Bruce wrote in his excellent essays (read them all!): the solution is political, not technical.

2 - The NSA has weakened security products and technologies to implement backdoors enabling them to spy on their targets.
  I'll be moderate on this one: THIS IS A CRIME AGAINST HUMANITY. No less.
  Weakening internet security will have, and maybe already had, terrific consequences. Who's a terrorist on this case?
  A backdoor is open for everyone who will spend the needed time to access it, for good or ill.

3 - Speaking of terrorism, according to what I know, no terrorist attacks were prevented by the NSA's mass surveillance. The collected data helped investigations after some successful attacks, such as the Boston Marathon bombing. But the cost of the data collection & storage is clearly prohibitive. Bulk-Collection is not efficient
  During FIC 2014, French military/intelligence representatives declared: "if you have nothing to hide, you don't need to fear our agencies' surveillance".
  This is unacceptable for several reasons:
  - The NSA was proven to escape Congress and democratic controls, our French equivalent, the DGSE is strongly suspected to do the same. How this kind of agencies can give any guaranty the information they collect will be used lawfully?
  - Internal unauthorized access is always a risk: some NSA personnel used collected information for personal goals (spying on their wives/husbands).
  - As every information security professional knows well: such a data store cannot be absolutely protected against external unauthorized access either.
  - The USA and France are democracies, so controls and reforms will be enforced now that we know, right? Alas, a democracy is always at risk. The French IIIrd Republic surveillance data were much useful to the Nazi political polices and to the Vichy dictatorship, between 1940 and 1944. No one would have expected such a situation before 1940.

4 - Whistleblowers
  Edward Snowden and Bradley (now Chelsea) Manning are considered heroes by some, traitors by others. I don't know. I only know the NSA behaved illegally.
  In both cases, they were rather low-level operators, a sub-contractor and a private soldier. If I were in charge of information security & security policy in either of their former organizations, I would have resigned immediately after knowing about their leaks.
  In the business world, there are legal mechanisms and contractual requirements obliging companies to enable whistleblowing and handle it properly. I don't know if such a system would work for intelligence agencies.
  But one thing is certain: to prevent leaks, don't have secrets, or as few as possible; and respect the law.

5 - The rest of the world is upset by what the NSA did and probably still does.
  Governments, even allied of the USA, were spied on. But I guess they do the same in return.
  Less friendly countries such as China and the Soviet... er... Russia, well... Didn't they know already? These two countries are the only ones whose intelligence agencies' budgets are comparable to the USA's.
  The golden rule in state to state spying is: do it, but don't get caught. I know it's sounding cynical, but less than a French officer at FIC 2014, who declared he thinks Snowden is a traitor to his country, but regrets there's no Chinese Snowden yet ;)
  But now that there are proofs of what the NSA did, other states will feel entitled to break the internet into useless isolated pieces. That would be another crime against humanity, and the NSA would have a part of responsibility in that.

6 - As an information security professional, I think the NSA scandal had at least one positive effect: bringing Infosec issues under mass media scrutiny; good point for public awareness.
  The news don't lack of high profile security breaches, but a spy story is clearly a better seller.
  Now, states secrets and spying are not the main interest of security professionals. We have much to do to protect our employers/clients/users against common criminals and thieves.
  More revelations will come from this NSA case, but I hope it will not disturb the Infosec field in 2014 as much as it did in 2013.
  One thing must be absolutely avoided: leave the Infosec and the fight against cybercrime become a domain exclusively reserved to the military & intelligence agencies. It's not their job, cyber war/spying is. Coordination between military and civilian is good, not subordination. I guess the Gendarmes & fellows I met at the Botconf 2013 will agree :)


Now, back to work. I've some ISO 9000/27000 stuff to do ;)


DISCLAIMER: Though I inserted many links to his articles in this post, I'm not related in any way to Mr Bruce Schneier. As a still newbie information security practitioner, I have of course a great admiration for him and for his work. Same for Mr Brian Krebs, though you can feel free to make a donation to his excellent blog ;)

Weapons Control, or not ?

Long time I didn't post anything on this blog, sorry, I was working on my CISSP exam, successfully passed, now waiting for recommendations and experience validation :)

For some years in the USA, the question of weapons control hits the news, more after every tragedy, for obvious reasons.
Many weapons like automatic rifles which are rather freely available in the USA are tightly controlled in most European countries.

Nevertheless, in some european big cities suburbs, this kind of weapons became easily available and affordable for gangs, after the war in former Yugoslavia and the fall of eatern Europe's communist regimes.
This was and still is a challenge for law enforcing forces and security companies (banks/ATMs, cash transport, jewel shops, etc.).

I'm not an expert in weapons, I won't try to argue for one side or the other.

My point here, is we seem to have a similar situation in our not so virtual world: iOS vs Android.

iOS is like an European country, with a tight policy preventing even legitimate and anti-malware software editors to have access to the low-level OS to build efficient protection software.

Android is more like the USA: the OS is more accessible, making life easier for malware creators AS WELL AS for anti-malware and protection software writers.

My 2 cents:

- The "fortress" of iOS will be breached, with devastating effects. Just an hint which is #1 here: Top 10 most Worrying Things We Saw at Black-Hat
  0-days on iOS are among the most expensive on the black market, which is a kind of limited and temporary protection: only state agencies/spies can afford them. For how long ?

- The "arms race" logic which will prevail on Android will hit more the security news in months and years to come.
  This will be an iterative process: more threats, counter-weighted by more protection techniques, and so on.

As a strong supporter of Agile methods and their iterative processes, you'll guess which side I'm on ;)
At least on the long term.

I don't say I have the same opinion about firearms control, but it's not the subject of this blog, and opinions can change.

The Roman Limes: Data Loss Prevention

One more lesson from History: Limes/Adrian's Wall.

Like the Maginot Line or the Chinese Wall, the fortified frontier built by the Romans never prevented barbarians intrusions.
But it had another more important mission: preventing or at least hindering their return with their spoil.

During several centuries before the Germanic tribes invaded and toppled the Roman Empire, small bands of them attacked the Roman fortified frontier.
It was rather easy for them to penetrate the Empire, as they chose the exact place of their attack after long observation of the defense weaknesses, and always by surprise.
Once in Roman territory, they wandered at will, as there were few if any in depth defenses.
But they were followed and tracked by their victims or some Roman scouts. So their way back to the frontier and to their own territory was guessed, reinforcement brought to the place, and it was far more difficult for the Germanic warriors to pass the Limes back.
The legend of the Rhine Gold comes from this, they say: so much of this stolen gold and goods was drought in the frontier river, it seemed the gods had cast a curse on it.

Nowadays, in Information Security, it is well known a perimeter defense like the Roman (fire)wall is not sufficient.
Most of Defense in depth techniques are also in a difficult straight.
Recent Advanced Persistent Threats proved Data Loss Prevention is not efficient or even not implemented at all.

Maybe we should overturn our priorities, just like the Romans did (and it worked well for three or four centuries):
- Monitor and log and focus our SIEMs on what happens INSIDE our infrastructure.
- Focus on what tries to GET OUT instead of on what tries to GET IN.
- Implement this monitoring and alert everywhere in the infrastructure: servers, network devices, desktops/laptops and mobile devices.
- Surely many more to do, educating users not the least...

Let's face it: I was probably an insider threat as well as most of us, even if we never noticed it. It's so easy to introduce a malware inside our perimeter by simply browsing a compromised web site or app store.

Comments and critics welcome! :)