January 29th, 2010
Recently, Imperva released a study (pdf) of the passwords extracted from the December 2009 RockYou security breach that resulted in the compromise of over 32 million user accounts. This study examined some statistics of the passwords retrieved, including the number and variation of characters use to construct them. The results were pretty bad. Here are the highlights:
-30% of users had passwords made up of 6 characters or less. Most brute force attempts are moderately successful against short passwords.
-Over 50% of passwords were all lowercase, or all numbers. This is bad because the keyspace is reduced. Even a password that is longer than 6 characters is weakened if it has a small character set distribution.
On the surface, these two statistics aren’t a good look at all, especially considering the ease with which an attacker could successfully guess simple passwords.
Also, in many cases, a password breach may not just make a user’s account vulnerable on the breached site, but can also lead to their account being compromised on other sites as well (plenty of people use the same password on multiple sites).
However, there is an alternative way to interpret this data. Although there is no way to verify this, it could be the case that users are starting to give value to the importance of some accounts AND the security of the website associated with it. And those accounts that are of low significance (like a site they just sign up on to play a game) get simple, easy-to-remember passwords, while accounts of greater personal significance (banks, primary email, etc.) get the more robust passwords. Similarly, it could be the case that users think sites like RockYou are sketchy anyway, and thus more likely to get hacked than other more-serious sites.
So, in a way, the user could be protecting themselves from a site breach. I know I wouldn’t care if I had a RockYou account and the site got breached since I wouldn’t really use that same password anywhere else important. It may be annoying, but it is much better than knowing that my super-secret 28-character password is sitting on some stranger’s computer simply because somebody left the door open.
So if you think of this report from the perspective of users managing risks reasonably instead of users being victimized, it almost makes sense that 29,000 people had ‘123456′ as a password.
Tags: data breach, password
Posted in data theft, passwords, privacy, users by
Nick Staples
| No Comments »
January 26th, 2010
According to a new article on TechTarget, a study by the Ponemon Institute has revealed the cost of a data breach has increased once again, to $204 per compromised record. The study is available for download at http://www.encryptionreports.com/ after giving away some personal details.
The “Fifth Annual U.S. Cost of Data Breach Study,” funded in part by encryption vendor PGP Corp., determines the annual cost of the breach by establishing a company’s cost of lost business as a result of an incident; expenses incurred by notifying individuals and authorities of a breach; costs associated with legal fees and consulting firms and new investments made in technology and employee education.
In our down economy, it is interesting that the cost of data breaches have been rising for five years running. If I were cynical, I might suggest that one of the reasons for the constantly increasing costs in this study is the partnership with PGP, who sells products designed to protect you in the case of a lost laptop or storage device.
That said, I’m not even sure that those items above can accurately represent the cost of data breaches, especially in certain environments. The loss or damage of reputation caused by a data breach can be so devastating that the monetary cost can’t even be calculated. If you don’t know what I’m talking about, what is the first thing that comes to your mind when I mention Heartland Payment Systems, TJX, or the Department of Veterans Affairs? These organizations have suffered tremendously because of wide (and widely publicized) data breaches. Imagine the firestorm of criticism if some of the most trusted companies were to suffer data breaches along the lines of Heartland’s breach?
In addition to the loss of reputation, what are other costs of data breaches that the Ponemon study doesn’t reveal? Let us know in the comments.
Tags: data breach, Encryption, pgp, ponemon
Posted in data protection, data theft, rants by
Peter Hesse
| 1 Comment »
January 22nd, 2010
It’s the news the penetration testers have all been long awaiting; Backtrack 4 final is here and now. Though many people, myself included, have been using various pre-release, beta release, and pre-final release flavors for almost a year now ever since first standing in line to hand over my usb stick to a group of elite hackers at Shmoocon 5, now there is no excuse. The final release is just in time for Hack or Halo at Shmoocon 6, saving me the trouble of making sure to update every tool I might possibly need before the big event.
So why does Backtrack rock in general? It’s basically most of the tools you will need for your pentest all rolled into one and set up nicely. I say most because it doesn’t have your commercial tools such as Nessus built in for obvious reasons, though it is possible to integrate your licensed Nessus into your Backtrack install. Ever been setting up Dradis for your first big pentesting gig at a new company on a recently imaged box? You’ve got your ruby prerequisites (rubydev, opensslruby, etc.), various gardening tools, SQLite, diamonds, garnets, and opals. At some point in the process of getting it all integrated, even your technically savvy individual may find himself ruing the day he decided it was a good idea to wait until the night before to build the pentest box. In Backtrack it goes like this:
root@bt4: cd /pentest/misc/dradis/server
root@bt4: ruby ./script/server
Done.
So why upgrade to Backtrack 4? First off, there’s the obvious perk of having the newest versions of all your favorite tools and some you’ve had on your list to check out for a while now. It also includes some new tools that have been developed in the interim since Backtrack 3 came out way back in summer of 2008, saving you the trouble of those pesky installs and svn checkouts. A great new tool that’s making its Backtrack debut on the final release of Backtrack 4 is re1ik’s social engineering toolkit (SET). Additionally, Backtrack 4 is Ubuntu based rather than Slackware based. While Backtrack 3 was great, your Ubuntu-based system has its perks as far as driver integration goes. As more and more people move from just the Live-CD Backtrack approach to using Backtrack as the base operating system on their pentesting boxes, this can only be a step in the right direction. Speaking of installation, Backtrack 4 final has an installation script that looks a lot like the GUI-based point-and-click installation wizards seen in system such as Ubuntu, resulting in a more hands-off approach than persistent changes in Backtrack 3.
The only drawback with Backtrack 4 as is that I can think of would be trying to write up your reports in Backtrack. Let’s not get into any holy war between writing in vi or nano, and just suffice to say it’s not easy. Backtrack 4 does come with Emacs, and some included tools such as Maltego make some pretty graphs. Plus, you can install OpenOffice on Backtrack, so it’s not that big of a drawback after all.
All in all, Backtrack 4 is the bomb, and if you haven’t jumped on the bandwagon, my advice is to get to it.
Georgia
Posted in Technology & Tool Thursday by
Georgia Weidman
| 3 Comments »
January 20th, 2010
ISACA has introduced a new certification for risk managers – CRISC. I’ve got their CISA certification, and I’m not sure that CRISC is useful (other than as a way to make them money).
First off, risk management is not specific to the IT field, and most risk managers are not working in IT but in project management. Second, there are very few risk management methodologies in use, or even studied, so what exactly does this certification teach/require? There are scant details on the web site on what the test will cover, but they claim that these professionals will help enterprises design risk management controls for IS. Risk isn’t only about controls – that’s auditing – making sure the processes you put in place are being followed!
Risk management isn’t only about determining and mitigating risk, it’s all about what are the risks and what are we going to do about them? I’m not sure these skills are easily taught, except through case studies.
Any project manager is going to understand risks better than most IT people will (unless they’re also a PM). Go for the PMP cert rather than this one.
Posted in rants by
Laura Raderman
| 1 Comment »
January 14th, 2010
Google has just announced that HTTPS access would be “on by default” starting immediately. This is in response to the recently publicized attacks against Google and Gmail which are causing Google to reconsider their approach to China.
While I’m happy that Google will now be encrypting Gmail-related communication by default, I’m a little surprised and disheartened that it took an attack to cause this to be implemented. Sure, https has been an option since July of 2008, but Google had previously warned of a security / usability tradeoff with turning it on:
Because the downside is that https can make your mail slower. Your computer has to do extra work to decrypt all that data, and encrypted data doesn’t travel across the internet as efficiently as unencrypted data. That’s why we leave the choice up to you.
Today’s computers are fast enough to handle https without concern, thank you very much. And I think they meant to say your encrypted email “can’t be cached by proxy servers” instead of “doesn’t travel across the internet as efficiently” – which is a good thing, right? The use of always-on-HTTPS is an infrastructure problem – establishing and maintaining all those different secure sessions with different keys certainly takes time and processing power. It is unfair to solve your infrastructure problem by suggesting that the user might not want comprehensive security.
Are you aware of any other services that allow the user to make a poor security decision in the (perhaps unjustified) name of speedier access? Let us know in the comments!
Tags: Gmail, Google, HTTPS
Posted in data theft, rants by
Peter Hesse
| 1 Comment »
January 12th, 2010
In the struggle between cyber attackers and cyber defenders, many tools have been built to create a strategic advantage or to gather intelligence. One category of software has the benefit of being both. Honeypots are a combination of software and hardware that emulate a target computer system or service for the purpose of attracting attackers and/or analyzing their attack. In essence, honeypots are tools used against attackers to both catch them red-handed and to figure out how they’re doing the dirt.
Attackers regularly scan large blocks of IP addresses in an attempt to find exploitable computers. When they think they’ve found a likely target, some form of attack usually follows. By placing honeypots on the Internet, security researchers are able to get a first-hand view of just how the attacker carries out his goal. Since the honeypot is no different from any other computer system from the perspective of the attacker, they are likely to never even suspect anything is wrong.
Honeypots may run under a virtual machine or within some other form of sandbox environment to protect the host computer from suffering any actual harm. The effect is similar to a glass-bottom boat, where all attacker activity is transparent to the researcher. Most honeypots advertise themselves by responding to scans as if they were a vulnerable service. For example, a honeypot may accept connections to TCP port 80 and claim that it is a webserver. The attacker will be inclined to believe that a webserver actually resides on the target computer at TCP port 80, even though this is incorrect. If the attacker attempts to attack the computer via that channel, the honeypot will log the effort for future analysis.
It can also be fun to set one up on your own computer and see what you catch. HoneyBOT is Windows honeypot software that lets you turn your system into a functional honeypot, ready to catch attackers in the act . If that’s your thing.
Posted in Uncategorized by
Nick Staples
| 1 Comment »
January 12th, 2010
SearchCompliance.com has posted an article detailing important regulatory compliance trends that will affect IT in 2010. The trends that were listed include:
- Automation of compliance processes
- More regulation en route
- FISMA compliance reform
- More enforcement for noncompliance
- Federal data breach and privacy laws emerge
- Cloud computing complicates compliance
- SOX compliance for small companies
- Migration to risk management
I was quoted in a couple parts of the article with my visions of the future related to FISMA and risk management. It’s worth a read and a comment if you think they missed anything, or if my predictions are way off!
Tags: Compliance, FISMA
Posted in general, regulations by
Peter Hesse
| No Comments »
January 8th, 2010
It’s all over the news; Google finally has an Android to call its own. The media is throwing around terms such as iPhone killer, but that doesn’t seem altogether likely to me. Perhaps it will level out to a PC vs. Mac sort of scenario. This actually sounds plausible as in my research I came across news of a project working on porting Mac OSX 7 to the iPhone, and the great big thing with Android back when I got mine was running Debian on the G1.
Read the rest of this entry »
Posted in Uncategorized by
Georgia Weidman
| 5 Comments »
January 8th, 2010
(probably) Everyone knows that firewalls are a “good thing” to have, but how many people actually know how they work?
Firewalls can have many features that I won’t go into here, but the basic way they work is that there’s a set of rules that someone sets up (or is given) and the firewall follows those rules. How it does this makes us remember our TCP/IP and UDP connection details.
A connection consists of two port/IP pairs – one for the source and one for the destination. A firewall looks at that information (among others) to determine if that packet is “OK” or not. If the packet is OK – based on the rules it’s been given, the “connection” is assigned an ID and the information added to a cache table. The cache table isn’t necessary, but it helps figure things out like “related” connections. It also helps with translation between IP addresses and ports if any NATting or DMZ ability is going on.
In addition to port/IP rules, a firewall can look at any field in the IP packet (and some look at anything in the layer 3 packet as well – including MAC addresses). So, a firewall can filter based on the type of packet it is (for example, not allowing ICMP packets – i.e. ping), what options are being used (like TCP flags), as well as content of the packet – although this is less common.
Firewalls can also alter any field in the IP packet, for example to support quality of service based on the port, or to change the IP address to support NAT.
What about this big cache table thing? Can it be “filled” like we can with ARP packets? Yes, it can, but as the cache is not *necessary* to the fundamental operations of the firewall, most will just not add things to the cache when new connections come in. It’ll imperceptibly slow things down since it has to run through the rules every time, but the firewall will still do its job.
Posted in Tutorial Tuesday by
Laura Raderman
| 1 Comment »
January 7th, 2010
Seems the new year has brought out a few new findings. One being the newly discovered “God Mode” feature in Microsoft’s Windows 7 based operating systems. At its core, it’s basically a glorified control panel. It takes all the hard to get to, or annoying multiple right click -> properties -> options -> submenu -> etc. -> etc. parts out of some of the common administrative tasks.
So, how do you get this miracle “God Mode”?
Read the rest of this entry »
Posted in Technology & Tool Thursday by
Tim Donaworth
| 4 Comments »