Google have announced they will start offering encrypted search capabilities over SSL shortly.
“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
Just a heads up that all the Internet’s root DNS servers have now switched over to DNSSEC 100% glitch free so far. Once this propagates down to ISP level support (who knows when this will be, maybe with IPv6…) we can finally verify the authenticity of DNS records hence putting an end to cache poisoning attacks and MITM DNS query interception. Steps in the right direction!
There have been various stories over the past month adding to why SSL is a broken technology for securing our Internet connections (people have been saying this for years).
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! —–> Read the rest of this entry »
Joanna Rutkowska, famous for her hypervisor/virtualization security research (bluepill), just blogged about a new OS they’ve been working on called Qubes, now at alpha release (Screenshots).
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.
Tools Required: Linux, Tripwire
Tools Optional: Sendmail
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.
Read the rest of this entry »
This is pretty bad! Still, this is the year of PDF exploits…
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!
Read the rest of this entry »
I’ve had a couple of people ask me recently if the MD5 hash function is still ok to use in web applications, so I thought I would write a brief summary on the subject. They gave excuses such as “the hash is hidden away in a database, end users will never see it…”, not a good thought process for security.
Short Answer: No, don’t use it any more.
Long Answer:
Read the rest of this entry »
Everyone knows you should shred sensitive documents, but did you know modern photocopiers often have inbuilt hard disks that store document scans? I didn’t!
“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.
Here’s a (verbose) guide I wrote on exploiting a slightly tricky buffer overflow vulnerability I had to do as part of a challenge. The vulnerability is an off-by-one error in the bounds checking. So it’s not a completely basic stack smash as there is a form of bounds checking in place, it should be a good tutorial/example to learn from if you’re relatively new to buffer overflows. If you’re very new to this, you should read Aleph One’s famous paper, and know basic memory layouts and terminology.
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.
#include <string .h>
#include <stdio .h>
void populateBuffers(char *argv[])
{
char buffer1[32], buffer2[32], buffer3[32];
strncpy(buffer2, argv[1], 31);
strncpy(buffer3, argv[2], sizeof(buffer3));
strcpy(buffer1, buffer3);
}
int main(int argc, char *argv[])
{
populateBuffers(argv);
return 0;
}
Read the rest of this entry »
Peter Vreugdenhil successfully exploited IE8 on 64bit Windows 7 at the Pwn2Own at CanSecWest. IE8 is often regarded as the most secure browser available today by many people in the industry, primarily because of the several layers of protections it’s wrapped in. Very impressive attack as ASLR & DEP have proved relatively robust to date, there’s a brief paper detailing the exploit techniques used here