By websites, I should really have said Web Applications, but the end result is the same: A server which is serving pages on the Internet could see its CPU usage increasing to a level making that server unusable for a few minutes or more. All that from a relatively small specially crafted malicious HTTP request.

This vulnerability exists in most languages used to develop web applications: PHP, ASP.Net, Java, Python, Ruby, etc. And it has been known to exist in theory since 2003!

Last week, Alexander Klink and Julian Wälde explained at the 28th Chaos Communication Congress in Germany how exactly the theory became reality and the impact on the different web application languages were affected.

The core of the issue is the way hash lists have been implemented in those languages. By “Hash” they both refer to a specific type of data structure and the cryptographic function. A Hash list is a type of data structure that is very popular because it stores and accesses data in a list very quickly. Before an object is inserted into a hash list, it is first hashed using a hash function to provide a “unique” hash reference which is then used to access and store the object in the list. To simplify, it replaces the usual [i] of a standard list with a [hash reference]. (“i” being an integer).

In reality those hash references are not so unique and collisions do occur. When it happens the objects with the same hash reference are daisy chained. The longer the chain and the least efficient hash lists become. Under normal operation it does not happen often and this is not a problem.

But as first highlighted by Scott Crosby and Dan Wallach in 2003, data/object stored into hash lists can be manipulated so collisions do happen more often. So much more in fact, it can degenerate the hash list resulting into the server’s CPU going overdrive and bringing the server to its knee in the process.

Alexander and Julian explained at 28c3, as shown in this video, that for Perl the issue was located in how the DJBX33A (PHP5) and DJBX33X (PHP4) functions were generating hashes. Other languages were also vulnerable because they were using very similar functions to generate their hashes.

With the help of CERT they communicated an advanced advisory to the relevant vendors and organisations in early November 2011, after they successfully implemented an attack for most of the languages used by Web Applications. They received different responses, some more satisfactory than others…

Ruby reacted very quickly and has a patch ready, Microsoft has issued a temporary work around for ASP.Net by limiting the number of parameters, PHP and Python needs more time and Oracle, although they have provided a patch for Tomcat and will in a near future do the same for Glassfish, stated that it isn’t an issue for Java. If you watch the 28c3 video you can easily understand they are wrong (clue for Oracle, go to the 32d minute or so). Therefore we should expect a Java patch for the HashTable and HashMap functions soon, albeit too late.

To conclude, this is a serious issue that has now a practical and known way to exploit it, with a global scope and high performance impact. Microsoft in a Technet article has provided a snort signature to detect this type of attack against ASP.Net, it should be fairly easy to adapt for other languages.

The recommendation is to both monitor for a patch related to your web applications (and implement it quickly when available) and to also monitor your network for such attacks (and try to block its source IP if not coming from a distributed attack). You should be reviewing what are the versions of the languages used by your Internet facing web applications and probably also ask your 3rd party partners what they plan to do about it!

A nice summary is also available on Arstechnica.

PS: Thanks to Thierry for pointing the story to me in the first place!

 

Two vulnerabilities in iOS5 have recently been discovered, one is affecting the iPad2 and the other the new iPhone 4S. In both cases it allows anyone to bypass any lock/passcode to gain unauthorised access to the device.

1) iPad 2 + iOS5 + SmartCover = Anyone can unlock your iPAD
This only affects iPad2 with iOS5 and the smart cover set to automatically lock the device.
With a locked iPad2, keep pressing the power button until you see the screen telling you to swipe to turn off, close the smart cover, reopen it and push the CANCEL button.
This will give you access to the latest application that was used. It means that if you were on the application listing screen you will be able to see all the applications installed on the iPad, but you will not be able to open any other applications. This is because you are in the “finder”/”Explorer” application.
But it also means that if before you closed your smart cover to lock your device you were in the mail application, using this technique would give you full access to the mail app and your emails.

To fix the issue you need to disable the smartcover autolock feature, until Apple fixes this bug.

2) iPhone 4S + SIRI
With SIRI enabled, even if you have locked your phone with a passcode, you can hold the HOME button and SIRI will be activated allowing you to speak commands such as call someone, send a text or an email, etc.
Although you cannot open applications this way, you can still do unauthorised actions as mentioned above.

To fix this issue you need to disable SIRI, until Apple fixes this bug.

What is somewhat surprising is that it is taking so long for Apple to fix these issues, They have been know for more than a week…

 

There is a recent BBC article on a new attack against a key component of Quantum Cryptography: Key Transportation.

There are 3 main components to a cryptographic system:
- The strength of the algorithms used (close/open, random generator, collision, etc)
- The integrity of the system (implementation, key storage, devices security, etc)
- The transportation of keys (no full or partial interception of the keys, etc)

Quantum Cryptography has for some been seen as the future for ensuring the integrity and detection of any interception attempts during key transportation.

I am not a Quantum Physic expert, but what I understand is that key transportation is done through light, where photons of light are sent to the receiver who will inspect the states of those photons to reconstruct the key. It is similar of sending a stream of bits which make the key, apart from the fact that in Quantum Physics a photon has not just a binary state (0/1 or -/+) but multiple values at the same time.
One of the key Quantum property useful for cryptography is that once a stream of photons is inspected, it is “destroyed” or changed. Therefore if someone was trying to evesdrop the receiver would know.

As a side comment, there are a few things that still puzzle me how this can only be a good thing. What about repeaters? you would need those to exchange keys to very far distances? So even if you can guarantee the key hasn’t been intercepted you cannot apply the same “quantum” guarantees to the repeaters (ref Integrity of the System). Furthermore, this could lead to a Denial of Service attack, I don’t see how Quantum Physic Key Exchange infrastructure could be as resilient as today’s internet. You would need specific “light tunnels”, if it gets damaged or if someone tries to intercept the key exchange even in the sole goal of disrupting the exchange process, then keys cannot be exchanged and the communication cannot take place…

Anyway, I would hope they must have thought about all this and have an answer. But what a team of scientists has just done, is to prove they could intercept the key and “blind” both ends into believing the exchange had been successful.

However some scientists have replied it was just a “configuration” problem with the system implementation and that it was possible to detect that attack after all.

Nonetheless, this adds weight to those who believe Quantum Cryptography is not the Saint Graal some claim it is, and that similar implementation issues there are today in “standard” cryptography also exist in “Quantum” Cryptography.

The BBC Article (Summary)
The Norwegian University Article where the paper came from (Original Article)
The Quantum Hacking Group responsible for the discovery (More info)

Below is a great video from the Quantum Hacking Group Website explaining the attack:


YouTube Direkt

 

In the past few months there seems to have been a rise in what is called Advance Persistant Threats (APT).
Wikipedia actually has a short but comprehensive description of what it means HERE.

An article on SC Magazine describes what seems to have been an APT against RSA affecting the security of their two factor authentication products.
It is not clear exactly what has been stolen at the moment, but RSA has admited that some sensitive information has been leaked/downloaded.

By reading some of the security community reactions (Help net security article) there seems to be 3 main concerns:
1. Security breach related to their pseudo random number generation, their product security would then be reduced to the security of the user’s passcode. Usually a simple 4 digits PIN.
2. The extend of their customer data that was stolen, could some of that data have an adverse effect of their customers (i.e.: password, name, addresses, etc)
3. What could be the security impact on the RSA 2 factor product users

The first concern is another example that security through secret is never good, and I am surprised RSA would only rely on some “secret fixed seeds” for their token code generation.

The second concern is typical of any data breach from a reseller/vendor who keeps large volume of customers data. The nature of the data and how it was protected will be of importance for RSA’s reputation.

Finally, the 3rd concern is what is of most significance. The common security community message seems to be: no need to panic.
Although I agree, I would add “but do not ignore it”.

It is important to remember that 2 factor authentication are used to improve the access security controls.
If the level of security it provides is reduced to a single factor authentication then there is an increased security risk towards what you were trying to protect in the first place.
This is even worse if that 2 factor authentication was the sole authentication method, as compromised tokens codes would then leave you with a very small 4 pin passwords.

Also, with todays popularity of “in the cloud” services many companies have replaced the physical security element where access was only accessible while on premises or from the company network, with a 2 factor authentication security control:
The “somewhere you are” requirement being replaced with a “something you have” requirement.

A compromised of the RSA token codes generation could have a very negative security impact on companies who are using RSA tokens to protect access to their cloud services.
They would indeed end up with portal accesses only protected by a userid and a 4 pin digits.
Now, if that is the case, this would be something to worry about and act upon.

 

Below is a very good article describing the recent battle between the Anonymous Hacking group and the HBGary company.

In a nutshell, a security company, “HBGary”, who is also working for the US government was about to release what they think were the identity of a hacking group called “Anonymous” who conducted some high profile hacks against large organisations who were against the wikileaks website. The hacking group response was swift and brutal, they hacked the HBGary websites, defaced them, hacked into the owner’s email account and grabbed lot of user personal information from one of the company’s related website, rootkit.com

It provides a good example of the old adage “do what I say not what I do” but this time in the world of IT Security. Of course you can almost never get IT Security 100% right, but in that case it would seem some of the security weaknesses that were exploited should have never been there or possible in the first place!

To add to what is already disccused in the article below, I think there was also a very basic security control missing in how that company operates/operated, the lack of a sensitive Information management process (email of both userid/password, no challenge response, etc).

Although this could act as a good reminder of “walking the talk” (another cliche!), I think it is unfortunately unlikely to change any company’s security agenda because in a corporate world where budget cuts, work load preassure, fast delivery is on the increase those kind of security practise shortcuts will remain, and so will the potential related attacks.
You could also argue there is a psychological aspect to this issue:
- The desire of doing favours for key people in the organisation, leading you to bypass procedures.
- Being over confident or expert in a field may drive you to neglect or being in deny of some basic issues.
- The need for trust in a working relationship may blind you to some questionable activities.

To get security right, one would need to be able to both take a step back, review and fix existing security issues while also moving forward with new technologies, changing IT landscape and fixing new security issues.

As this hacking incident illustrated, it is a very difficult balance to get right.

ARSTECHNICA Article on Anonymous vs HBGary

Update from the 1st of March:
It has costed HBGary Federal CEO’s role:
https://threatpost.com/en_us/blogs/hbgary-federal-ceo-aaron-barr-steps-down-022811

 

A few websites have been running a story today on an upcoming attack announcement/demo in next week black hat conference.

Instead of targeting the OS or a specific app, that attack would target bugs directly in a component used to send and receive calls, a baseband chip. Although technically it is still a software attack, the code used to control that chip, it would bypass any security measures in place at the OS level, and would especially be out of Apple/Google control. Such attack could be used to intercept calls or spy on a phone user by activating its phone microphone…

But then surely you would also need to find a bug in the microphone chip? Or elevate your privilege at the OS level from the baseband chip bug?
Anyway, eavesdropping on calls would at least be possible.

What makes this news interesting is both that duplicating a cell tower is becoming easier/cheaper (about $2k) and that you can’t secure and control everything, even in close systems such as iOS devices. Until they start manufacturing every single component, phone manufacturers will have to rely on a multitude of other vendors; all with different security agendas.

Now, if I was working for a security state agency I would invest in some key communication component companies… As hacking is becoming more and more lucrative/political, how long until the “bad guys” start thinking alike… but then you would call me paranoid ;)

Below is a link on the first website I read that story today:
MACWORLD

 

The recent hack on PS3 where the private key used by Sony to sign their games has been recovered is of course a very bad news for Sony. It finishes to open the door to piracy which started in January 2010. In theory, anyone could now sign (pirated) software to run natively on the PS3.

It is a case of badly implemented cryptography algorithm, in that case, the use a proprietary signing algorithm with a faulty random generator.
Crypto 101 says to NEVER use proprietary/secret algorithms. Now Sony’s will pay the price for not listening :)
The PS3 hack story is a great example of badly implemented cryptography which is as important as the choice of the security controls used to protect an asset.

BBC NEWS ARTICLE

The start of an answer from Sony, which seems to indicate they did not grasp the severity of the issue when first announced about a week ago
MYCE ARTICLE and THIS ARTICLE TOO with more info.

And finally, much, much more info about the hack on the PS3NEWS SITE.

© 2011 Encryptsolutions Suffusion theme by Sayontan Sinha