Au programme de cet article (testé sur Debian Wheezy) :
Mises à jour : cron-apt et checkrestart Sécurité virus : clamav, malwares maldet, rootkits rkhunter, chkrootkit, lynis vérification de l'intégrité des paquets : debsums nettoyage : deborphan, ... backups
la plupart des commandes ci-dessous nécessitent d'être root ou d'utiliser la commande sudo tous ces logiciels ont normalement des logs dans /var/log, et c'est TRÈS utile pour trouver pourquoi ça ne marche pas il faut avoir un logiciel de mail configuré (comme postfix) pour pouvoir envoyer des mails n'oubliez pas de RELANCER le programme après une modification pour la prendre en comptes
CVE 2015-023: Nasty bug in glibc gethostby* functions leads to possible wealth of remote code execution opportunities. : netsec
"A heap-based buffer overflow was found in __nss_hostname_digits_dots(), which is used by the gethostbyname() and gethostbyname2() glibc function call. A remote attacker could use this flaw to execute arbitary code with the permissions of the user running the application."
The Node Security Project team has been working alongside the Node.js community now for more than a year. Our goal is to identify vulnerabilities in the open source module ecosystem that people use and love, provide quantifiable action items when these threats are found, and assure that patches get landed, helping developers ship better secure code.
Using NSEC is relatively simple, but it has a nasty side-effect: it allows anyone to list the zone content by following the linked list of NSEC records. This is called 'zone walking'. The 'ldns' library contains an tool called 'ldns-walk' that can be used to list all records inside a DNSSEC signed zone that uses NSEC:
For some DNS zones, this is an issue. The NSEC3 record option in DNSSEC solves this by creating the linked list using hashed domain-names, instead of clear-text domain names.
A few months ago I decided to get started on fuzzing. I chose the reference implementation of the Network Time Protocol (NTP), ntpd, as my first target, since I have some background with NTP and the protocol seemed simple enough to be a good learning experience. Also, ntpd is available for many platforms and widely in use, including being part of the default OS X installation.
Advisory: Drupal - pre-auth SQL Injection Vulnerability
Release Date: 2014/10/15
Last Modified: 2014/10/15
Author: Stefan Horst [stefan.horst[at]sektioneins.de]
Application: Drupal >= 7.0 <= 7.31
Severity: Full SQL injection, which results in total control and code execution of Website.
Risk: Highly Critical
Vendor Status: Drupal 7.32 fixed this bug
Today we are publishing details of a vulnerability in the design of SSL version 3.0. This vulnerability allows the plaintext of secure connections to be calculated by a network attacker. I discovered this issue in collaboration with Thai Duong and Krzysztof Kotowicz (also Googlers).
Côté serveurs, les actions concrètes :
Apache avec GnuTLS : GnuTLSPriorities SECURE:-VERS-SSL3.0
Apache avec OpenSSL : SSLProtocol -SSLv3 -SSLv2
Nginx avec OpenSSL : ssl_protocols TLSv1.2 TLSv1.1 TLSv1
Postfix avec OpenSSL : smtpd_tls_protocols = !SSLv2,!SSLv3
Serveurs IMAP Dovecot : ssl_protocols = !SSLv2 !SSLv3
Serveurs IMAP Courier : TLS_PROTOCOL="TLS1_2:TLS1_1:TLS1"
Rainer Gerhards, the rsyslog project leader, reported a vulnerability in Rsyslog, a system for log processing. As a consequence of this vulnerability an attacker can send malformed messages to a server, if this one accepts data from untrusted sources, and trigger a denial of service attack.
For the stable distribution (wheezy), this problem has been fixed in version 5.8.11-3+deb7u1.
The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).
Tester ses serveurs:
Surveiller ses connexions:
tshark -i eth0 -R "ssl.record.content_type eq 24 and not ssl.heartbeat_message.type"
Hey, it's Will. I was recently working on a proof of concept (PoC) exploit using nothing but the CERT BFF on Linux. Most of my experience with writing a PoC has been on Windows, so I figured it would be wise to expand to different platforms. However, once I got to the point of controlling the instruction pointer, I was surprised to discover that there was really nothing standing in the way of achieving code execution.
It is often told that Linux Containers (LXC) are not secure. This was definitely true 3 years ago, but they got much better. Here is a quick overview of current challenges, as well as ways to improve ...
LXC 1.0: Your first Ubuntu container [1/10]
LXC 1.0: Your second container [2/10]
LXC 1.0: Advanced container usage [3/10]
LXC 1.0: Some more advanced container usage [4/10]
LXC 1.0: Container storage [5/10]
LXC 1.0: Security features [6/10]
LXC 1.0: Unprivileged containers [7/10]
LXC 1.0: Scripting with the API [8/10]
LXC 1.0: GUI in containers [9/10]
LXC 1.0: Troubleshooting and debugging [10/10]
One of the most prominent denial of service attacks in recent months was one that occurred in March 2013 between Cloudflare and Spamhaus. One writeup of this attack can be found here. I'm not sure about the claim that this attack "almost broke the Internet," but with a peak volume of attack traffic of some 120Gbps, it was a very significant attack nevertheless.
How did the attackers generate such massive volumes of attack traffic? The answer lies in the Domain Name System (DNS). The attackers asked about domain names, and the DNS system answered. Something we all do all of the time of the Internet. So how can a conventional activity of translating a domain name into an IP address be turned into a massive attack?
We can't undo the improvements to DNS security. If we did, the DNS would once again be an untrustworthy and unreliable source for data. To move forward, we must figure out a way to eliminate reflection attacks and continue on with our security strategies. Or rethink these strategies overall.
On the horizon: expanding the role TCP (transmission control protocol, one of the core protocols of the Internet) plays in the DNS. Historically, expansion has been a taboo subject because TCP doesn't make much sense for DNS, but it removes the effectiveness of reflection attacks, for the most part. While there are reasons not to utilize TCP — another topic for another blog post — the fact is that DNS is already defined to operate over TCP, despite years of building devices that assume it doesn't. While this is a subject to experiment with, it's not a certain solution.
Other options exist, but it is too early to even begin to describe them. New topologies and new arrangements are in the works. Other changes to the protocol are being considered. Where we go next is anyone's guess.
Cryptocat is run by people that don't know crypto, make stupid mistakes, and not enough eyes are looking at their code to find the bugs. Cryptographers know the minimums or at least know you should look them up. Cryptocat tried BPKDF2, RSA, Diffie-Hellman, and ECC and managed to mess them all up because they used iterations or key sizes less than the minimums. There was a bug in the generation of ECC private keys that went unchecked for 347 days. They seem to not understand simple programming concepts such as a byte vs a decimal digit character: "Fix inaccurate comment". Both comments are wrong since "Cryptocat.randomString(64, 0, 0, 1, 0)" generates a string that is 64 decimal digits which is 212.6 bits or 26.6 bytes.
What do I think of Cryptocat?
Cryptocat's public key scheme is now good after being bad since pretty much the beginning. I would suggest not using Cryptocat as there's no telling how long it will be until they break their public key encryption. Good news is if they read this they'll make a better effort not to change public key algorithms or the way they generate private keys. I'm sure there are plenty of bugs and other bad crypto in other parts because I only looked at random generation and found a bug, at public key algorithm and found a bug, and quickly looked where random is used and found something scary.
What did I get out of this?
Even though I qualified for their bug bounty I never got anything. My guess is my bug is too big. Since it means that all messages after May 7th, 2012 are crackable. In a comment I was ask for my name, but I have not been added to their bug hunt page. I guess should have "t-shirt, sticker, money, and a mention on our Wall of Unquestionable Greatness!" coming sometime, but haven't heard anything about it.
Well I had fun writing DecryptoCat. Also I learned a new word "encraption". Thanks for that one azonenberg from irc.freenode.net. Also I learned that it means nothing when I hear "it is open source and peer reviewed".
For this post, I'll be analyzing the following browsers on a Windows 8 machine. Here's a table of contents for this post to help you skip to whatever browser you're interested in:
Chrome 27.0.1453.110 IE 10 Firefox 21.0
During the time that the RSA patent was in force, DSA was the signature algorithm of choice for any software that didn't want to deal with patent licenses. (Which is why lots of old PGP keys are still DSA.) It has slowly disappeared since the patent expired and it appears that 4096-bit RSA is now the algorithm of choice if you're on the run from the NSA . (And if you're a journalist trying to get a reply: keyid BDA0DF3C.)
But DSA can also be used with elliptic curves in the form of ECDSA and, in that form, it's likely that we'll see it return in the future, at least to some extent. SSH and GPG both support ECDSA now and CAs are starting to offer ECDSA certificates for HTTPS.
Unfortunately, DSA has an important weakness that RSA doesn't: an entropy failure leaks your private key. If you used a machine affected by the Debian entropy bug then, in that time, messages that you encrypted with RSA can be broken. But if you signed anything with a DSA key, then your private key is compromised.
Ever wondered how those key files in ~/.ssh actually work? How secure are they actually?
As you probably do too, I use ssh many times every single day — every git fetch and git push, every deploy, every login to a server. And recently I realised that to me, ssh was just some crypto voodoo that I had become accustomed to using, but I didn’t really understand. That’s a shame — I like to know how stuff works. So I went on a little journey of discovery, and here are some of the things I found.
When you start reading about “crypto stuff”, you very quickly get buried in an avalanche of acronyms. I will briefly mention the acronyms as we go along; they don’t help you understand the concepts, but they are useful in case you want to Google for further details.
The whole concept of security awareness training demonstrates how the computer industry has failed. We should be designing systems that won't let users choose lousy passwords and don't care what links a user clicks on. We should be designing systems that conform to their folk beliefs of security, rather than forcing them to learn new ones. Microsoft has a great rule about system messages that require the user to make a decision. They should be NEAT: necessary, explained, actionable, and tested. That's how we should be designing security interfaces. And we should be spending money on security training for developers. These are people who can be taught expertise in a fast-changing environment, and this is a situation where raising the average behavior increases the security of the overall system.
If we security engineers do our job right, users will get their awareness training informally and organically, from their colleagues and friends. People will learn the correct folk models of security, and be able to make decisions using them. Then maybe an organization can spend an hour a year reminding their employees what good security means at that organization, both on the computer and off. That makes a whole lot more sense.
Summary: Security always requires a multi-layered scheme. SSH is a good example of this. Methods range from simple sshd configuration through the use of PAM to specify who can use SSH, to application of port-knocking techniques, or to hide the fact that SSH access even exists. Applying these techniques can make life much harder for possible intruders, who will have to go past three unusual barriers.