Vulnérabilité dnsmasq : qui est affecté ?

Google a révélé un ensemble de vulnérabilités affectant le serveur dnsmasq, couramment utilisé dans la gestions des réseaux informatiques. Ces failles permettent à l'attaquant d'exécuter des commandes de son choix sur le serveur vulnérable, ce qui peut ouvrir la porte à une intrusion plus vaste du réseau. Ces failles sont maintenant corrigées, à condition bien sûr de mettre à jour ledit serveur vers la dernière version.

Nom du logiciel : dnsmasq
Versions vulnérables : toutes jusqu'à la 2.78
Fonction : serveur DHCP, serveur DNS
Gravité : grave
Lieux d'utilisation : boîtiers Freebox, certains serveurs ClouData, certains serveurs Wanadoo, certains serveurs DNS et DHCP publics, beaucoup de réseaux auto-administrés.

Les POC côté serveur ont été publiées par Google. Il n'existe pas pour l'instant de méthode simple publiée pour tester un serveur depuis le côté client.

Shellshock, Exploiting Bash Vulnerability Through Apache CGI

You may have read about it anywhere else, yet I insist on fixing this one straight on.
The story: a Bash vulnerability has been reported as CVE-2014-6271 and later as CVE-2014-7169 (as it was uncompletely fixed). It allows arbitrary code execution when the content of a variable is parsed, that is, every now and then in shell scripts. If the content of the variable comes from user input, then this is a way for the user to execute arbitrary code, with current local rights.

One way this can be exploited is via Apache CGI (or nginx CGI). These have been provenly found to be exploited on the web, so this is no unnecessary crying wolf. CGI uses shell (Bash) to parse web request headers such as Host or User-Agent and allows arbitrary code execution with the administrative rights of the web server daemon itself. I succeeded in exploiting it for audit purposes, showing there is no need to be a lifelong-expert to proceed.

Although exploits of this vulnerability have reportedly been spotted only by use of Apache/nginx CGI, there could very well be other exploits of any server that uses Bash to parse user input, which means virtually any server undex Unix/Linux (think: Apache without CGI, cups, postfix, databases...)

The following command, launched from a server Bash shell, let's you know if the server is vulnerable to this vulnerability. Unless you did something specific in the last days, it's highly unlikely that your server will not be vulnerable.

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

So, I dearly recommend to patch Bash itself. If you cannot patch or must delay patch application, making sure no CGI scripts are exposed or CGI is disabled is a temporary workaround.

Saving Money with IT Security Processes. Example 12/26: Avoid Website Defacement with Vulnerability Management

Article number 12 in a series dedicated to giving examples of the way IT security processes can help your company save money.

Vulnerability Management is the process that helps your information system stay up to date with patches that fix vulnerabilities in the software you use. One striking example is: with correct Vulnerability Management, you won't get any of your websites defaced.

Please note that it can't be reduced to just using another piece of software to update it all. No single piece of software can possibly fix everything on a regular basis, nor can it fix problems with the best acumen. It's the Vulnerability Management process. It does the following:

• Technological Watch for all currently used pieces of software and technologies. This means subscribing to newsletters or feeds from every single related vendor and reading them.
• Whenever a new vulnerability has been spotted, identify whether the company is affected or not.
• If it's affected, check how much it would cost to suffer from the exploitation of the vulnerability and compare with the cost of applying the patch or workaround.
• Have it put in action.

The Vulnerability Management process is not always identified as a process per se, but sometimes distributed in the Technological Watch and Patch Managements processes.

Saving Money with IT Security Processes. Example 6/26: Reducing Project Delays with Secure Project process

Article number 6 in a series dedicated to giving examples of the way IT security processes can help your company save money.

Projects have a conception phase. In this phase, networks are designed, interactions with users are designed and so on. This is a moment when thinking critically with a security mindset is most valuable.

If you let the conception phase evolve without a security engineer, IT people will think about networks but not about intrusions. They'll think about users but not about attackers. Because that's the security job. So, they will design vulnerable software, networks and/or servers.

Then the vulnerable conception will be implemented and put into production. Then either the Security Audit will spot vulnerabilities and ask for a costly patch (or re-design) or the Security Audit will miss it and a security incident is going to happen soon. Both cases are very expensive for a company.

If you have a sound Secure Project process, with a goal to secure developing projects, this will not happen and the company will save a lot of money.


The whole case in this article is based on two little known asymmetries:

1. You can look for a vulnerability at the conception phase or at the production phase. But doing it in production is longer (more expensive) and is more likely to just fail spotting the vulnerability.
   
   
2. You can patch a vulnerability at the conception phase or at the production phase. But doing it in production is longer (more expensive), may require stopping production (lost business hours) and may trigger side-effects.