OpenVPN isn’t anything new. But today I finally overcame a hurdle I had with trying to connect to our company VPN via my Android device. The OpenVPN for android project isn’t anything new; it’s actually been in the works since late 2009 if you follow it all the way back through a couple forks.

The main issue that was holding me up wasn’t anything to do with Android-OpenVPN port itself. It was simply to do with the Android device I was using (thanks Samsung for crapping on us with the Galaxy S devices). A recent ROM update finally put the final pieces I needed into motion for being able to utilize OpenVPN. The main holdback was the lack of tun in the kernel of my Android build.

(more…)

As you’ve doubtless heard, Sony’s PlayStation Network has been down for several days now. The exact cause of this outage, being apparently affected by hackers of some stripe, is doubtless worth investigating. However, since those details haven’t been fully divulged yet, it’s best to wait on that front.

But this brings to light an increasing problem: the erosion of standalone functionality. PSN customers have not been able to access online content since April 20th. This is, of course, to be expected – if you shut off the network, the network is not available. Unfortunately, this extends to content which isn’t actually hosted on Sony’s network, since PlayStations use the PSN to connect to outside servers. Still, though, not surprising.

Vexingly, however, a certain amount of offline content has also been rendered unavailable, specifically several Capcom games which apparently need internet connection even for single-player mode. This seems to be an increasing trend in the software industry, in games of course, but in other software as well. Even software which has no need to be online, such as a word processing suite, increasingly needs to authenticate with a server in order to install. In fact, you might have noticed that most builds of MS Windows have just such an authentication requirement. And this is continuing to the next level: the Google CR-48 laptop as almost no functionality without an internet connection. Woe betide the user who truly does not want to ever connect a machine to the Internet!

But why would someone want to keep their computer offline?

Well, security, for one. The “airwall” remains the strongest form of security available; no code can ever bridge the gap of a true lack of connection. This isn’t solely the province of super secret government facilities, after all: medical facilities, industrial applications, and numerous other facilities can achieve higher security by dint of simply not connecting machines to the Internet when it is not needed.

Some may not be able to achieve an Internet connection, either due to cost or lack of infrastructure. As amazing as it may seem in 2011, Internet access is not available everywhere, nor to everyone.

But the most important reason is highlighted by this PSN debacle: why should Internet access be necessary? The Internet is a powerful, pervasive tool – but it’s not the end-all of the computing experience, and even now there’s no reason that a computer should be rendered a paperweight by simple lack of connection.

So, last night I downloaded a version of the Low-Orbit Ion Cannon, the traffic generation tool which Anonymous has been using to attack various websites. The version I acquired, from SourceForge, was not one which had been modified for use by Anonymous – it didn’t have the “Hive” function which allows it to be utilized remotely. I should mention that although it was originally made by Praetox, and many versions available for download still have Praetox branding, Praetox no longer supports the code, nor is in any way affiliated with Anonymous.

It’s not really a terribly complicated tool. All it does is flood out requests in one of three ways: http requests, TCP packets, or UDP packets. It allows the user to specify the target by URL or IP address, the timeout, port number, the number of threads used, and the attack mode – that being http, TCP, or UDP. If using http, the user can specify the subsite, and if using TCP or UDP, the payload can be given. There’s also a slider for the speed – though no information on what the actual bandwidth will be – and a checkbox for whether or not to wait for a reply. With this set of parameters given, the user need only tell it to go by hitting a button entitled “IMMA CHARGIN MAH LAZER” and watch the status across the bottom.

It’s not a very sophisticated tool; it doesn’t have anything to help it get past even rudimentary countermeasures. Given that it was written as a load-testing tool, that’s hardly surprising. What it lacks in sophistication, it does offer in simplicity. This is a tool which is simple, intuitive, and effective. In terms of usability, a great many professional developers could stand to learn from it. This is a tool which can be used with virtually no networking knowledge. Given that it’s a tool which is being given out to people with virtually no networking knowledge, it’s not a bad fit.

LOIC isn’t exactly a major threat to a large website. As is the nature of DOS attacks, it simply uses a brute-force attempt to flood a site. Smaller servers can readily be overwhelmed, of course, but this isn’t a new issue. That being said, LOIC has proven remarkably effective even though it is hamstrung both by its simplicity and by the steps users must take to preserve their anonymity while using it. So long as groups like Anonymous retain a use for such a tool, newer versions can be expected. While they may have newer tricks, they’ll likely remain by the curve technologically, preferring to keep the same simple usability which allows LOIC to be wielded by so many people.

How do you know which ciphers your SSL service supports? The best way to find out is to ask, and that’s exactly what SSLScan does. SSLScan is a command-line tool that, given an address and port, will generate a long list of ciphers and report whether the SSL service at the location accepted or rejected them.

You can find a Windows port here. The tool also displays preferred ciphers, supported protocols, and the server’s SSL certificate.

A couple of weeks ago, we brought to your attention the newly released two-factor authentication that Google rolled out for all of its web-based products (Gmail, Google Docs, Google Calendar, etc.). So now that it’s been out for a few weeks, and it’s finally had a chance to make its rounds to everyone’s accounts, let’s take a step back and see how it actually works.

We’ve talked about the importance of two-factor authentication in the past, and even a few other areas where it’s implemented.

Google did an excellent job at throwing together some tutorials on how to set-up everything and ensure your experience is pleasant. I would go into a detailed tutorial on all of this myself, but really I doubt I could do a better job than they did. But for those who just wanted a quick refresher, here goes. You can also read a fairly straight-forward take on everything directly from Google themselves and learn how it works.

1. Setup
2. Signing in with verification codes
3. Signing in using application-specific passwords

(more…)

I didn’t think Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) made much of a splash when it arrived. I vaguely remember hearing about it, and only decided to check it out when I saw a tweet about it. The basic idea is that it acts as an extra layer of protection against the current generation of exploits in Windows. It has the ability to force processes to use DEP and ASLR, which can significantly lower the success rate of certain attack vectors when used in tandem. Although ASLR has been around for a few years, typically the protection had to be compiled into the code and tested first. So EMET comes in handy for new programs that don’t opt-in to ASLR, and for older programs that were never compiled with ASLR support in the first place.

In the future, I’d expect persistent ASLR to be included as an OS security option (like DEP). Until then, EMET is probably the easiest way to make sure a Windows program has some protection against some of the tools of the opposition.

Stop and think about what an attacker could do if they gained control of your e-mail account. Many web sites let you reset your password via an e-mailed link. Poorly designed services may even send a copy of the password to your inbox. Much of your personal information is likely reflected in conversations you’ve had via e-mail, and services such as Gmail can store copies of all your messages.

With all this in mind, protecting access to your e-mail has become an important priority. Using strong passwords is a great starting point, but that’s only one level of security. Many companies use another system, known as two-factor authentication, to protect sensitive data, but it hasn’t been widely deployed for consumer services.

Today, however, Google is making two-factor authentication available to users of Gmail – or any other service that involves a Google account. That means that instead of logging in by simply providing information you know (your password), you also have to prove you have something: your mobile phone. Whenever you login at a particular computer/browser for the first time, you’ll be prompted for a secondary code that’s either sent to you as a text message or generated with an app on your iPhone, Blackberry, or Android device. This gives you another layer of defense against phishers and hackers trying to access your inbox.

The new feature is not enabled by default, since it requires a phone and will likely be unfamiliar to most users. But you can enable it on your Google Accounts by visiting the Account Settings page and look for “Using 2-step verification” under Personal Settings. More information is available at the Google blog.

I had the good fortune to attend ShmooCon 2011 last weekend. A new tradition at ShmooCon is evening “firetalks” on Friday and Saturday. Basically, after the conference has ended for the day, a bunch of folks decide to put off parties for a few more hours in order to do a bunch of 15-minute “get right to the point” talks. This year had a good selection of topics and speakers, with one that jumped out to me as a perfect topic for this week’s “Technology & Tool Thursday” post.

Armitage was written by Raphael Mudge (not to be confused with Peiter “Mudge” Zatko). It’s a GUI interface for using Metasploit to pwn your targets. Metasploit is a tremendous framework for writing and launching attacks, but it can get a bit daunting, plus it may not always lead to the most efficient attack patterns. Instead, Armitage helps make everything easy by taking away a lot of the command-line ninja voodoo necessary to make things tight and effective. You can now download it as part of the Metasploit tree, or you can set it up independently. There are plenty of details in the online manual.

The best recommendation I can give for learning more is to go watch the firetalk. You can do that over —> here. Raphael walks through several demos as he counts down the 10 reasons Armitage makes Metasploit hacking fast and easy.

Many information security blogs, including this one, have discussed the recent data breach of gossip site Gawker and problems associated with leaked passwords. The story has demonstrated some of the risks associated with password storage. Gawker did store passwords using a form of encryption, but it was a weak algorithm and thus the encrypted data could be cracked. It’s important to remember that you should never simply rely on “encryption” to protect information – that’s sort of like say a bicycle is protected with a combination lock. Some locks are easier to open than others, and if the lock is attached to a weak cable or not properly looped through the frame of the bike, its strength doesn’t even matter.

With passwords, though, another option is available: one-way hashes. A hash function takes an input of data, such as a password, and outputs a value that’s always the same length and format. The algorithm is designed so that it’s easy to calculate a hash, but essentially impossible to reverse the process. Also, slight adjustments to the input drastically change the output value, and the chances of two values leading to the same hash are extremely unlikely. To use another analogy, think of a person’s fingerprint. It’s easy to capture a fingerprint using an ink pad and paper. But if you start with a fingerprint and want to identify the person it came from, you’re at a loss without a database of records to check. And once again, finding two identical fingerprints from two different people would probably never happen.

If an application stores the hash of a password instead of the actual password or a value generated by reversible encryption, then theoretically, the password would remain safe if the database were ever breached. When a user tries to log in, the application simply generates a hash of the supplied password (remember, generating hashes is easy) and compares it against the stored hash. If they match, the user has given the right password. If not, the password is wrong.

Just as people have built databases of human fingerprints, however, databases of hashes exist for common values, so only using a hash would not protect users with simple passwords. Weaknesses have also been found in older hash algorithms, such as MD5. Better options include SHA-1 and the various versions of SHA-2, but they are still not sufficient on their own. Extra protection comes from adding “salt.”

In this context, salt refers to an extra string of random information that’s unique for each saved record. This salt is then concatenated with the password and a hash is generated for the entire new string. The salt needs to be saved along with the hash in the database so that login passwords can still be verified, but it should still be kept secret as much as possible. When a user logs in, their supplied password is concatenated with the salt, hashed, then checked against the stored hash.

With this system, an attacker who manages to break in to the database will only recover salted hashes instead of actual passwords. The nature of hash algorithms means that even if a user had a simple password, the salt helps ensure that their hash won’t match any found in common hash databases. To figure out each password, an attacker would have to compute all possible values with each individual salt, vastly multiplying the amount of computation required.

Of course, just as toothpaste manufacturers remind buyers that their products are only one component of good dental health, salted hashes are only one part of a secure application. In fact, with technologies such as OpenID, OAuth, and Facebook Connect, many sites really don’t even need to handle user passwords any more. But if your application does require its own authentication, a robust implementation of salted hashes ought to be a baseline for password security.

Enter Armitage. If you’re normally a windows/GUI person and aren’t comfortable with the command line (much less metasploit’s command line), you might want to look into Armitage. It uses xmlRPC to talk to metasploit and presents you with a nice pretty picture of your network and what you’ve compromised and allows you to launch metasploit plugins and attacks against the networks, as well as interface with meterpreter to pivot through compromised hosts.

I have only scratched the surface of what Armitage can do in my own testing, but what I’ve seen so far has been excellent – especially for an initial release.

Some folks will complain that this makes it too easy to “hack” into things, but I really think it’s an improvement for those professionals that have other things to do than memorize metasploit’s command line or have to read through the manual every time they use it (raises hand).