At some point I moved overseas to study and Lockup fell by the wayside. I now write the occasion post over at “Written by Glenn”. Come say hi.
The first is the ability to create hidden encrypted operating systems when using whole-disk encryption. This works in a similar fashion to hidden encrypted disk containers. That is, you have a primary boot partition that is encrypted with one password, and a second virtual one that is contained within the primary, but encrypted with another password. The password you enter will determine which partition is loaded and, without knowing the password, it is impossible to know that there is a second hidden operating system. This is called plausible deniability and allows you to have a “decoy” or “safe” operating system to open if, for example, you were under duress. While most of us aren’t spies, this feature may still come in handy.
The other new features are more performance and reliability enhancements. TrueCrypt is now multi-core aware, so if you’re creating a lot of encrypted disks, the time to encrypt them will now be halved on a dual-core, quartered on a quad-core, etc. In the area of reliability, the team have added header redundancy so you have a greater chance of recovering a damaged container or partition.
For regular use, you probably won’t notice a lot of difference, but none-the-less, it’s another great release from the TrueCrypt team.
Older versions of almost every popular implementation of DNS (eg. BIND, Windows, Cisco, Solaris, Juniper) have a vulnerability which would allow an attacker to “cache-poison” the server. This means that a compromised server, possibly your ISP’s, could direct you to fraudulent websites.
For example, this sort of attack could mean that if you typed http://www.paypal.com into your browser, a cache-poisoned DNS could direct you to an IP address that is not operated by PayPal, but the address bar would still say http://www.paypal.com. This attack can not spoof the PayPal SSL certificates, but could list one with a similar name, making this an extremely dangerous phishing technique.
One would hope all the major ISPs and public name servers would have patched this vulnerability, but it’s likely that smaller servers, such as at businesses, universities or individuals, may not have.
Test your DNS server here, many large ISPs have been very slow to patch:
If this test shows your DNS to be vulnarable, change your DNS settings to the ones specified at OpenDNS.
I’ve finally finished my OpenVPN guide. It’s based on the guide I used from It’s a Tech World, but I’ve beefed up the security and added explanations and detail to some of the more complicated steps.
Here is the URL (it’s linked from the homepage as well): https://lockup.wordpress.com/configure-openvpn/
As I mentioned in a previous post, using this configuration of OpenVPN, you’ll be able to securely connect to your host network from anywhere, access files, services and the host internet connection, but you’re host network will remain completely invisible to ports scans.
This product is amazingly effective, simple to use (once setup) and, with the right configuration, secure. I think my guide is fairly comprehensive, but if you have any suggestions, feel free to comment.
Big thanks to Riley at It’s a Tech World for writing such a great guide.
This isn’t new, but worrying. A ransomware virus from over a year ago, called ‘gpcode’ has resurfaced. The new version is called ‘gpcode.ak’.
What’s interesting about this virus is that, when infection occurs, it encrypts a victim’s documents (.doc, .pdf, etc) and leaves a ransom note on the computer demanding money in return for the decryption key. The original version of this particular virus used a 660-bit asymmetric key which was eventually cracked, but this new version uses 1024-bits. The internet security company Kaspersky has stated:
“Along with antivirus companies around the world, we’re faced with the task of cracking the RSA 1024-bit key. This is a huge cryptographic challenge. We estimate it would take around 15 million modern computers, running for about a year, to crack such a key.”
Obviously this is very bad news for anyone infected by gpcode.ak, but it does provide some evidence as to the strength of good cryptography. For example, in the OpenVPN guide I’m putting together, I recommend using a 2048-bit key for certificate generation. That’s 2^1024 harder to crack than a 1024-bit key and, going on Kaspersky’s calculation, it would take 15 million modern computers 2^1024 years to crack. While computers are always becoming more powerful, this sort of key strength will surely remain safe for some time to come.
There’s a good page explaining all the details of gpcode.ak here.
As the name suggests, OpenVPN is an open source VPN package. What isn’t immediately obvious is that, rather than using the more popular PPTP or L2TP/IPsec VPN protocols, OpenVPN uses SSL/TLS (using the OpenSSL toolkit). I’ve been playing with this free product for the last week and have been very impressed.
While PPTP and L2TP/IPsec are certainly the more popular VPN technologies, just by taking a look at their Wikipedia pages (here and here) it would seem that they are neither the most secure nor the most straight forward to set up.
While I can’t say that OpenVPN has the most user-friendly setup process, with good instructions it’s fairly straight-forward and, once it’s up and running, it’s mightily secure. In fact, from the outside world, it’s nearly impossible to detect it’s even there (but more on that later).
OpenVPN works in a client-server arrangement. On your host network, you install a copy and drop in a config file to designate it as the server. You then generate the client-server SSL/TLS certificate pairs and set up passwords, ports, etc. Once that’s done, you can port forward from your router to the OpenVPN server on your host network, allowing you to access it from remote networks.
On the client (eg. your laptop), you run the same install file, but use a client config file. You then drop the certificate files you just created onto the client machine and boom, you have yourself a VPN.
While it’s not quite as easy as I’m making it out to be, as I’ll explain, it’s well worth the hour or two (plus the inevitable time for annoying mistakes).
The reason I’m so pro-OpenVPN is that it implements some very cool technologies. The first being SSL/TLS for tunneling. Being so widely used on the web, this protocol has been proven to be secure. In addition, it is also very routable and you can change the inbound port number on your router to work on 80, 443, etc if you think you’ll be working on restrictive networks.
Using SSL/TLS also means that you’re using certificates for authentication. OpenVPN let’s you generate 2048-bit certificate pairs, so unless an attacker actually has a client certificate, they can forget it. Even if your laptop was stolen, your certificate can be password protected, giving you plenty of time to delete the certificate pair from the server to render it useless.
Another nice touch is the option to use UDP, which is much less susceptible to attack due to its connectionless nature. I also like the flexibility to choose any encryption cipher in the OpenSSL toolkit, including the speedy yet secure AES-128.
But, in my opinion, what seals the deal is a lesser known feature called TLS-AUTH. As I mentioned briefly, even with OpenVPN running and with port forwarding on, it’s impossible for anyone but the client machines to solicit a response from your OpenVPN server. That’s because, with TLS-AUTH turned on, the server requires that all handshake packets be signed with a predefined cryptographic string, called an HMAC signature. This signature is stored in one of the files you copy to each client. Any packets sent to the server that haven’t been authenticated with this signature are dropped cold, so it appears to the would-be attacker that there is no machine at all.
On top of all this, initiating a VPN tunnel from a your laptop couldn’t be easier. You double click a system tray icon, enter a password and it’s done. From then on it’s just like you are plugged into the host network. You can browse file shares, use network services (eg. VoIP or Exchange) and browse out through the host internet connection. It’s nice when you can get this level of functionality for such a small sacrifice to security and I can certainly say that OpenVPN has the best functionality to security ratio that I’ve seen. In addition, it’s free.
In the next few days I’ll be posting a comprehensive guide to setting up OpenVPN. It will be based on a couple of guides I’ve used, official documentation and a lot of Googling. I hope it’ll prove useful.
In the meantime, if you’d like to read up on OpenVPN security, just Google it. There are a bunch of good articles.
EDIT: The guide is finished, you can can view it here.
NAC involves verifying the integrity of a system before granting it access to a network. This might involve checking that anti-malware is up-to-date, the OS is patched and that group policies have been applied. The aim of this is to stop attacks on new systems as they join a network and to protect a network from compromised systems.
NAC is generally enforced by client software, which is now included in XP and Vista (but called Network Access Protection), with the latest round of service packs. Security vendors such as Symantec, McAfee and Sophos have also have packages released to market.
This approach to network security seems much more comprehensive and seamless than using combinations of software, group policy, scripting and user priviledge control, but increased security always comes at a price.
One of the greatest difficulties with implementing NAC is the challenge of authenticating and monitoring non-PC devices such as VoIP phones, network printers and IP security cameras. While exceptions could be made based on IP or MAC address for such devices, if a rogue system spoofs these addresses, NAC could be bypassed. Developing secure ways to authenticate and verify the integrity of such devices will not be a trivial task.
Challenges aside, this is a promising technology for enhancing the security of any network.
Read more about NAC here.
I use TrueCrypt to encrypt anything sensitive on my USB drive and I sleep extremely well at night, knowing that no-one in their right mind would try to break its 256-bit AES encryption. While I know that it’s theoretically possible to do so, it doesn’t really matter, because nothing I have is worth dedicating a server farm to brute force it. Some people do have data that important on their USB drives, and that’s why there’s IronKey.
TrueCrypt’s greatest weakness is that it is susceptible to offline attacks. That is to say, if someone gets hold of a TrueCrypt volume, they are able to try a variety of techniques to guess the password, with computer power being their only limitation. TrueCrypt places no limit on how many times you can attempt a password. IronKey, on the other hand, limits you to ten consecutive incorrect attempts. After that, it destroys all the encryption keys and data. For good.
IronKey was developed as a piece of security hardware and, as such, has a bunch of features which make it, to my knowledge, the most hacker-proof data storage device on the market. Not only does it limit the number of incorrect passwords before self-destruct, it also ensures that even the encrypted data cannot be removed from the device, which means it is not susceptible to offline attacks.
First off, you can’t see any data without first authenticating with the device. Second, if you try to physically tamper with the device, the epoxy filling in the device will cause the data and encryption chips to break. Last of all, the device is electron-shielded, so you can’t scan it to elicit data. It’s sturdy metal-cased and epoxy-filled construction keeps your data safe from unintentional physical damage too.
All this, along with hardware-based AES encryption, makes for a very secure device. If you have data that’s worth paying US$79 (for the 1GB version) to protect, take a look. If you’re like me, TrueCrypt is still a phenomenally secure solution.
While it’s unclear as to what the extent (“internet communication” is the specified term) of the proposed legislation is, the Australian government has suggested that offering these new powers to employers will aid the prevention of denial of service attacks on the country’s digital infrastructure.
This can be ridiculous in one of (at least) two ways. The first is that, hopefully, this was drafted by government advisors who actually do have an understanding of technology, but Ms. Gillard either does not or has dumbed-down her announcement for the mass media. The second, and more concerning, is that, the government actually believes that this sanctioned invasion of privacy by corporations justifies the minimal amount of national security information which could be obtained from employee emails.
One of the examples the government has mentioned is that of a distributed denial of service (DDoS) attack. If such a threat were to propagate through email, surely email virus filtering would be a better thing to mandate than this proposed law. What about simply providing organisations with solid advice on network security policy? Prevention is better than a cure.
The other implication with the “anti-terror” label is that “terrorists” might be sending each other notes at work. While no-one can say for sure, practically speaking, who would use a work email to swap bomb recipes? There are more subtle ways to send sensitive information.
It’s one thing for a government to have power to intercept personal emails (which many, including the Australian government, do), but giving those rights to private citizens (eg. network admins) crosses the line.
If a company really wants this power, they can stipulate it in their employee contracts. While not great, at least the employees are informed. On the other hand, this sort of legislation will serve only to unnecessarily increase government powers and the powers of employers, without our consent.
Who’s winning here?
Most of the phishing emails I see are obviously fakes. Many don’t bother to spoof the sender address, clearly link to third-party sites (eg. http://www.yourbank.com.46dyu.ru/verify/) and/or use terrible grammar and spelling. While it’s always a give-away when I’m not actually a customer of the purported bank, a few emails certainly make me look twice before I work out their trick.
Here’s one allegedly from St. George bank in Australia.
Have a look at their official website: http://www.stgeorge.com.au/
Then this email:
While some of the grammar is slightly amiss, this email is a step above the bulk of what I’ve seen. Their trick, while not new, is that the text, http://ibank.stgeorge.com.au/verify, is HTML linked to a phishing site at http://www.stgcorge.com/verify, much like I can have http://ibank.stgeorge.com.au/verify link to Google or anywhere else. Only in the case of this email, on a cursory glance, “stgcorge” could easily be read as “stgeorge”.