Until slides and papers are published, you can find some nice reports (all in French). But the most impressive will remain the challenge: look at the solution! What a hell! Just reading and trying to understand all details in the solution is still challenging!

Big respect for the guys who have the talent of going over so many tricks.

Taking a decision whether to use it or not requires some deep knowledge, because if its pros are clear – you can count on the salesmen to get a great picture of it again and again, its cons are silenced.

Too bad, a major disadvantage is security. But guess what? The other day an “analyst” presenting his study about cloud computing just cleared out the issue in 3 words :

“Concerning the people who doubt of the security in the cloud, it is a typical psychological issue of theses persons fearing change or something new . There is really nothing concrete to worry about cloud security.”

Well, not sure I am going to see a psychologist. Of course the guy did not give any solid argument, so here we go.

In short, cloud computing expose to the Internet services that were, in normal conditions, always kept inside an internal network and behind peripheral protections.

Of course, these services offer authentication, but basically almost every traditional web attacks will work as usual. After all, we are talking about the same web portal, the same users, the same browsers, etc.

Let quickly summarize the potential threats: CSRF, XSS, phishing, SSL attacks (MiTM, certificate spoofing),  browser exploits and many more.

So really, it is not a question of being crazy, paranoid or reluctant to change. There are just many issues that don’t make the cloud useless but should incite to caution.

Cloud computing can be used for what it is good at (flexibility, convenience) but not to replace a datacenter. It should not be used if security is a concern.

Don’t listen to the salesman only, read what some specialists are saying. Here is a compilation of some interesting articles I found :

• Black Hat 2009 presentation : pdf and summary
• Owasp presentation (pdf)
• Dangers in the cloud
• So you think *your* capability model is bad? (browser’s weak design)

And last but not least, in case our favorite salesman keeps pushy:

• Amazon EC2 vulnerabilities
• Salesforce phishing incident

But that’s not all. The same goes with “virtualization everywhere”, but that will be another topic…

“This is an OpenID Server, Nothing to See Here… Move Along”

I could not find what as wrong, as all prerequisites were fulfilled, until I find this nice post. The patch there works very well, thanks to the author (it is a shame that it wasn’t yet included in the trunk).

This and the lack of active open-source development around OpenID seems to show that it is not really popular. It is a shame because it is a pretty good solution against the multiplication of passwords. I wouldn’t want to use OpenID for my bank account access, but it is just right for many sites, forums, etc. Unfortunately, no many sites are yet OpenID enabled and the choice when you want to become your own provider is very limited (most of projects listed in the official wiki are dead, with no update for the last 2 years).

Hacking: the next generation

The purpose of this book is to give to the readers an overview of the most common attacks nowadays. It covers all fields : social engineering, web attacks, networking, etc.
It was easy to read : the authors are straight to the point and their sentences are clear.

I especially appreciated their state of art about XSS and CSRF attacks. It is certainly the best I have read so far, greatly illustrated with exciting and real case studies.

On the other hand,  I quickly passed over the networking stuff (both wired and wireless). It was too basic and didn’t show anything new – maybe it is because I specialize in those fields.

Anyway, globally, I strongly recommend this book. It is worth while your money if you want to know more on web attacks or to have a good overview of modern threats.

Beautiful Security

This is a collection of essays by some of the best security experts and hackers.

Well, I won’t go around, I have been quite disappointed by this book. The overall lacks coherence and after a while you start wondering what this book is trying to demonstrate. At the end, there is a crual lack of connection between the essays and it globally makes it appear very confusing.

It also sometimes lacks technical references and the writing style is too verbose, too literal for a technical book to be attractive.

There are however some good essays, like one about PGP (by Philip Zimmermann himself, though). It is hard to find some good and complete documentation about it, and this essay is definitely a good one, which I will probably read again when I feel the need of it.

But I wouldn’t recommend this book only for this short piece of writing. Lack of cohesion, too much litterature and not enough technical stuff actually bored me, though that’s just my personal taste.

I tried it out and I must say that the new UI is great. I am not a big fan of Flash and I regret this choice. However, the design is excellent, all options are accessible in a logical way. Instead of spreading over the options like it used to be, they come to you in the right order.

I also appreciate that the server and the client set-up are now unified thanks to the web interface (you can access it from localhost or from the network indifferently).

The report section has also been greatly improved.

So, if you were already an Nessus user, it is worth upgrading.

Talking about the set-up, there is an up-to-date package for openSUSE (of course, there are a lot less dependencies than before).

It is vulnerable to a MiTM attack where the attacker can intercept and retrieve the credential to a trusted HTTPS website, by intercepting the session cookie sent back to the client.

A proof of concept of an attack against Twitter was made.

Fine. But so far, the answer was to just disable any renegociation.

This actually causes some issues with SSL session timeout and totally broke client authentication.

I got into problems because of the latter. I am using client authentication for some location of my web server, and I recently could not connect anymore to these with the following log in apache :

[Tue Nov 24 16:56:15 2009] [debug] ssl_engine_kernel.c(1912): OpenSSL:Exit: error in SSLv3 read client hello A
[Tue Nov 24 16:56:15 2009] [error] [client x.x.x.x] Re-negotiation handshake failed: Not accepted by client!?

I first was not aware of the openssl patch and tried almost anything possible. My focus was, of course, on the certificate and the client.
But, a nice guy on IRC #suse, Stittel, had a good hunch and suggested me to look at the CVE-2009-3555 fix.

After more tests, it was quickly confirmed to work well with older versions of OpenSSL (as shipped in Debian Lenny).
Finally, I downgraded the OpenSSL version on my openSUSE box to a version prior to the CVE-2009-3555 fix and it just worked fine.

Then, I dig into it and found a lot of interesting reports there and there. So far it is a real mess.
In short, the breakage will stay as long as browsers don’t also include a patch to avoid renegotiation.
So far, I could not find a browser that does include a patch.
If anyone reading it knows a version that does it, please let me know.

Meanwhile, you have actually the choice between :

• low security by deactivating client authentication on your server
• low security by keeping a vulnerable version of OpenSSL

As my server is not very exposed, I chose the latter, but that’s not satisfying.  It is not recommended, but if like me you need to use client authentication with mod_ssl on openSUSE 11.2, do :

% zypper install --from repo-oss openssl openssl-certs libopenssl0_9_8 libopenssl0_9_8-32bit

where repo-oss is the alias to the 11.2 release (without updates) on your system.

What a brutal way to fix an issues without much notification and consideration to the users ! Even the log message is wrong and just confusing the administrator…

PS 1 : thanks again to Stittel for the good hint (I hope you will come by here) and to the always nice and helpful #suse channel in general ;)

PS 2 : bug reported on openSUSE bugzilla

Mark Dowd (IBM) and Alexander Sotirov (VMWare) found a way to bypass  the memory protection implemented in Vista to inject malicious instructions within Internet Explorer. They were able to copy any content wherever they wished on the disk.

Especially, this paper will be an interesting reading, even if it is not as simple as they say – at least for me.

It is especially usefull if your website is dynamic, involving php, sql, javascript, etc. With such a complex environment, as you can never be sure that your website is not vulnerable or up-to-date enough, something like mod-security provides an interesting extra-security layer.

Due to license issues, mod-security is no more shipped with Debian – it was until Debian Sarge.

Fortunately, the Debian maintainer continue to provide some packages on his website.

So, the easy way to set up mod-security on your Debian system is to add this line in your /etc/apt/source.list file :

$ echo "deb http://etc.inittab.org/~agi/debian/libapache-mod-security2/ etch/" >> /etc/apt/source.list

Then type in the usual sequence :

$ aptitude update && aptitude install libapache-mod-security2

You could also download the source from the official website.

Once it is done, comes the configuration part. The configuration is critical because any mistake on it will make it at best useless, or at worst blocking your website.
You have the choice between creating your rules from scratch or getting some ready made.
Creating your rules will require a lot of time and expertise in the http protocol, php, sql, and any other service that you offer with Apache.
That was not really my case, so I started to look for some ready made rules on google. I could not get good ones. Most of tutorial gives only some very basic and incomplete rules : useless. I found a good paper, notably containing some specific rules for WordPress, but the rules were written for mod-security v1 whereas it is now in its second version.
Oh, did I forget to tell you ? Most of the syntax was changed between the two versions !!! Not very nice, even if it was worth doing it.

Finally, I came to find a way with the rules provided by this website, Got Root ?. They provide quite up-to-date rules, with a delay of 30 days subscription-free, which is quite acceptable for what I want to do. After all, Php exploits and Sql injection technics don’t change every day.

The rules are also complete and spread over several files, one for each category in : generic rules, blacklist, usergents, proxies, rootkits…

We can fetch them with a little script. They suggest to add it as a cron job, but you should not, except if you don’t mind that your website becomes unavailable ! These rules always require testing, some of them may be broken or require customizing… be careful and always check what’s inside the rule files !

Here is the small script, modsec.sh, that I made to retrieve the rules and put them in the right directory :

#!/bin/sh

wget http://www.gotroot.com/downloads/ftp/mod_security/2.0/apache2/apache2-gotrootrules-modsec2.0-latest.tar.gz
if [ -e apache2-gotrootrules-modsec2.0-latest.tar.gz ]
then
tar -xzvf apache2-gotrootrules-modsec2.0-latest.tar.gz -C /etc/apache2/modsecurity/
fi
rm apache2-gotrootrules-modsec2.0-latest.tar.gz
/etc/init.d/apache2 restart

Make it executable and run it :

# chmod +x modsec.sh
$ ./modsec.sh

Now, let’s edit the /etc/apache2/apache2.conf file.

Just before these lines (probably at the bottom of the file) :

# Include the virtual host configurations:
Include /etc/apache2/sites-enabled/

Add these :

#Turn the filtering engine On or Off
SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess Off

# Handling of file uploads
# TODO Choose a folder private to Apache.
# SecUploadDir /opt/apache-frontend/tmp/
SecUploadKeepFiles Off

# Maximum request body size we will
# accept for buffering
SecRequestBodyLimit 131072
# Store up to 128 KB in memory
SecRequestBodyInMemoryLimit 131072
# Buffer response bodies of up to
# 512 KB in length
SecResponseBodyLimit 524288

SecDebugLog /var/log/apache2/modsec_debug.log
SecDebugLogLevel 0
# Serial audit log
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus ^5
SecAuditLogParts ABIFHZ
SecAuditLogType Serial
SecAuditLog /var/log/apache2/modsec_audit.log

#should mod_security inspect POST payloads
#SecRuleScanPOST On

# by default log and deny suspicious requests with HTTP status 500
SecDefaultAction log,auditlog,deny,status:403,phase:2,t:none

#First, add in your exclusion rules:
#These MUST come first!
Include /etc/apache2/modsecurity/exclude.conf

#Application protection rules
Include /etc/apache2/modsecurity/rules.conf

#Comment spam rules
Include /etc/apache2/modsecurity/blacklist.conf

#Bad hosts, bad proxies and other bad players
Include /etc/apache2/modsecurity/blacklist2.conf

#Bad clients, known bogus useragents and other signs of malware
Include /etc/apache2/modsecurity/useragents.conf

#Known bad software, rootkits and other malware
Include /etc/apache2/modsecurity/rootkits.conf

#Signatures to prevent proxying through your server
#only rule these rules if your server is NOT a proxy
#Include /etc/apache2/modsecurity/proxy.conf

#Additional rules for Apache 2.x ONLY!  Do not add this line if you use Apache 1.x
Include /etc/apache2/modsecurity/apache2-rules.conf

As you can see, we just include the rule files we just downloaded. You can easily activate or deactivate some to fit your needs.

You will probably notice that there is a performance impact after activating mod-security – not so big to me, but it also depends on your traffic. It is up to you to optimize the number of activated rules to make it faster.

If some page appear to be blocked, check the /var/log/apache2/error.log for something like :

[Fri Jul 11 19:33:08 2008] [error] [client 192.168.222.21] ModSecurity: Access
denied with code 500 (phase 2). Match of "rx ^HTTP/(0\\\\.9|1\\\\.0|1\\\\.1|1\\
\\.2)$" against "REQUEST_PROTOCOL" required. [id "340000"] [msg "Bad HTTP Proto
col"] [severity "ALERT"] [hostname "www.phocean.net"] [uri "/"] [unique_id "72F
col"] [severity "ALERT"] [hostname "www.phocean.net"] [uri "/"] [unique_id "72F
mG38AAAEAACa@AVUAAAAA"]

The ID number of the blocking rule is given. Just grep to find the faulty rule and correct / deactivate it :

$ grep 340000 /etc/apache2/modsecurity

Regxp knowledge required ! :D

I have had no time so far to check all the keys on my server. I prefer to stay on the safe side, though I have some reason to believe that my keys might not be so vulnerable : I generated them a long time ago, maybe before the Debian maintainer sad mistake.

It is going to be pretty easy now, for those who are motivated, to get access to the ssh server running keys generated during the 2 last years…

I recommend this article which summarize pretty well the situation. You may also use this tool, which checks if your keys are vulnerable :

$  perl dowkd.pl file ~/.ssh/*.pub

It find it funny to think that I chose to use certificates for security (avoiding brute force attacks).
What’s less funny is the pure disaster for the reputation of Debian.

I already noticed in the past that some companies switched their servers from Debian to Red Hat because of such security problems. They claimed about some security holes being patch much too slowly and about the lack of official support to rely on in such a crisis.
This kind of news is not going to enforce trust from companies.

I myself will think twice in the future about what system to use when I design my networks.