Tag Archives: security

Pour ceux qui pensent que les choses avancent…

Bruce Schneier


‘il y a bien quelqu’un qui me scotche régulièrement par ses réflexions et sa capacité à les transmettre, c’est bien Bruce Schneier. L’intervention qu’il a donnée l’an dernier à TEDxPSU était de celles-ci. La vidéo que je vous propose ici également :

Mais avant de la lancer, je vous propose de jouer à ne pas regarder l’écran. Éteignez-le, fermez les yeux, regardez ailleurs… Écoutez plutôt…
Puis posez-vous cette simple question : de quand date cette conférence ? Quand vous aurez la réponse, vous comprendrez mieux le titre de ce billet…

Pour ceux qui n’aiment pas jouer, il s’agit d’un talk donné à Beyond HOPE en… 1997…

Abusing HTTP Status Codes to Expose Private Information

When you visit my website, I can automatically and silently determine if you’re logged into Facebook, Twitter, GMail and Digg. There are almost certainly thousands of other sites with this issue too, but I picked a few vulnerable well known ones to get your attention. You may not care that I can tell you’re logged into GMail, but would you care if I could tell you’re logged into one or more porn or warez sites? Perhaps http://oppressive-regime.example.org/ would like to collect a list of their users who are logged into http://controversial-website.example.com/?

Ignoring the privacy implications for a second, as a website developer, you might like to know if your visitors are logged into GMail; you could use that information to automatically fill the email fields in your forms with “@gmail.com”… Perhaps you might want to make your Facebook “like” buttons more prominent if you can tell your visitor is logged into Facebook at the moment? Here’s how I achieve this:

…read more

Artillery 0.1 alpha – New tool for Linux Protection by ReL1K

Artillery 0.1 alpha – New tool for Linux Protection by ReL1K
A new Tool “Artillery” – for Linux Protection has been Released by ReL1K (Founder DerbyCon, Creator of the Social-Engineer Toolkit). It’s written in Python and completely open-source. Artillery is a combination of a honeypot, file monitoring and integrity, alerting, and brute force prevention tool. It’s extremely light weight, has

Pentesting IPv6 vs IPv4

We’ve heard a bit of “noise” about how IPv6 may impact network penetration testing and how networks may or may not be more secure because of IPv6.  Lets be clear, anyone telling you that IPv6 makes penetration testing harder doesn’t understand the first thing about real penetration testing.

Whats the point of IPv6?

IPv6 was designed by the Internet Engineering Task Force (“IETF”) to address the issue of IPv4 address space exhaustion.  IPv6 uses a 128-bit address space while IPv4 is only 32 bits.  This means that there are 2128 possible addresses with IPv6, which is far more than the 232addresses available with IPv4.  This means that there are going to be many more potential targets for a penetration tester to focus on when IPv6 becomes the norm.

What about increased security with IPv6?

The IPv6 specification mandates support for the Internet Protocol Security (“IPSec”) protocol suite, which is designed to secure IP communications by authenticating and encrypting each IP Packet. IPSec operates at the Internet Layer of the Internet Protocol suite and so differs from other security systems like the Secure Socket Layer, which operates at the application layer. This is the only significant security enhancement that IPv6 brings to the table and even this has little to no impact on penetration testing.

What some penetration testers are saying about IPv6.

Some penetration testers argue that IPv6 will make the job of a penetration testing more difficult because of the massive increase in potential targets. They claim that the massive increase in potential targets will make the process of discovering live targets impossibly time consuming. They argue that scanning each port/host in an entire IPv6 range could take as long as 13,800,523,054,961,500,000 years.  But why the hell would anyone waste their time testing potential targets when they could be testing actual live targets?

The very first step in any penetration test is effective and efficient reconnaissance. Reconnaissance is the military term for the passive gathering of intelligence about an enemy prior to attacking an enemy.  There are countless ways to perform reconnaissance, all of which must be adapted to the particular engagement.  Failure to adapt will result bad intelligence as no two targets are exactly identical.

A small component of reconnaissance is target identification.  Target identification may or may not be done with scanning depending on the nature of the penetration test.  Specifically, it is impossible to deliver a true stealth / covert penetration test with automated scanners.  Likewise it is very difficult to use a scanner to accuratley identify targets in a network that is protected by reactive security systems (like a well configured IPS that supports black-listing).  So in some/many cases doing discovery by scanning an entire block of addresses is ineffective.

A few common methods for target identification include Social Engineering, DNS enumeration, or maybe something as simple as asking the client to provide you with a list of targets.  Not so common methods involve more aggressive social reconnaissance, continued reconnaissance after initial penetration, etc.  Either way, it will not take 13,800,523,054,961,500,000 years to identify all of the live and accessible targets in an IPv6 network if you know what you are doing.

Additionally, penetration testing against 12 targets in an IPv6 network will take the same amount of time as testing 12 targets in an IPv4 network.  The number of real targets is what is important and not the number of potential targets.  It would be a ridiculous waste of time to test 2128 IPv6 Addresses when only 12 IP addresses are live.  Not to mention that increase in time would likely translate to an increase in project cost.

So in reality, for those who are interested, hacking an IPv6 network won’t be any more or less difficult than hacking an IPv4 network.  Anyone that argues otherwise either doesn’t know what they are doing or they are looking to charge you more money for roughly the same amount of work.

Netragard, LLC. — The Specialist in Anti Hacking.


Today the German hacker group “The Hacker’s Choice” officially released a new DDoS tool. The tool exploits a weakness in SSL to kick a server off the Internet.

Technical details can be found at http://www.thc.org/thc-ssl-dos.

“We decided to make the official release after realizing that this tool leaked to the public a couple of months ago” said a member of THC who wants to remain anonymous.

The tool departs from traditional DDoS tools: It does not require any bandwidth and just a single attack computer (“bot”).

The THC-SSL-DOS attack is en par with other resource exhausting DDoS attacks. Some of those methods played a vital role in demonstrations against oppressive governments (like the DDoS attack against Iran’s leader) and against companies that violate free speech (like the DDoS attack against Mastercard for closing Wikileak’s non-profit donation account because of an alleged typo/misspelling in the application form).

“Here at THC the rights of the citizen and the freedom of speech are at the core of our research”, says a member of THC in a private interview this morning.

“We are hoping that the fishy security in SSL does not go unnoticed. The industry should step in to fix the problem so that citizens are safe and secure again. SSL is using an aging method of protecting private data which is complex, unnecessary and not fit for the 21st century.”, Says a THC member, referring to 3 major vulnerabilities disclosed in SSL over the past 3 years.

To list the 3 major vulnerabilities here THC explains: “In 2009 a vulnerability was disclosed that broke the encryption of SSL. De-facto making all SSL traffic unsafe. In 2011 various Certification Authorities got hacked. De-facto making all SSL traffic unsafe _again_.”

“We warned in 2002 about giving hundreds of commercial companies (so called Certification Authorities) a master key to ALL SSL traffic.”, says Fred Mauer, a senior cryptographer at THC. “Only a real genius can come up with such an idea!”.

“And last but not least the immense complexity of SSL Renegotiation strikes again in 2011 with the release of THC-SSL-DOS.”.

“It’s time for a new security model that adequately protects the citizens.”.

The THC-SSL-DOS tool is a Proof Of Concept tool to disclose fishy security in SSL. It works great if the server supports SSL Renegotiation. It still works if SSL Renegotiation is not supported but requires some modifications and more bots before an effect can be seen.

Our tests reveal that the average server can be taken down from a single IBM laptop through a standard DSL connection.

Taking on larger server farms who make use of SSL Load balancer required 20 average size laptops and about 120kbit/sec of traffic.

All in all superb results.

Interesting here is that a security feature that was supposed to make SSL more secure makes it indeed more vulnerable to this attack:

SSL Renegotiation was invented to renegotiate the key material of an SSL connection. This feature is rarely used. In fact we could not find any software that uses SSL Renegotiation. Yet it’s enabled by default by most servers.

An old saying comes true all over again: Complexity is the enemy of security.

“Renegotiating Key material is a stupid idea from a cryptography standpoint. If you are not happy with the key material negotiated at the start of the session then the session should be re-established and not re-negotiated”, says THC.

  1. THC-SSL-DOS: http://www.thc.org/thc-ssl-dos
  2. Reverse SSL: http://eprint.iacr.org/2006/212.pdf
  3. DDoS explained: http://en.wikipedia.org/wiki/Denial-of-service_attack
  4. http://www.ietf.org/mail-archive/web/tls/current/msg07553.html

Share this:

Like this:

Be the first to like this post.