Some interesting numbers surfaced in research performed by Cyber-Ark Software recently regarding how willing employees are to take corporate data. In this research (published @ darkreading), Cyber-Ark surveyed 600 employees in financial districts and found that 41 percent have already taken info from one job to another and roughly a third would give the info to family and friends if it would help them get a job. The study went further to state that 85% of the people surveyed knew it was illegal to perform this action. The study continues to paint a grim picture with additional statistics that I will leave for you to read at your leisure.
The real question is: What do we do about this sort of Data Leakage? How do we prevent this from happening?
Unfortunately, for many organizations Data Leakage of this sort is often dealt with through written policy and employee contracts. In both cases, many organizations fail when it comes to enforcing either of these measures.
If you are truly concerned about your organization's data, where it may be going, and who down the line will be seeing it... Now is the time to think about actual solutions for reporting and enforcing Data Leakage.
Reading the latest MacWorld magazine (March-2010), I almost fell out of my seat. I could not believe what I was reading. (In retrospect, I can completely believe it, which is unfortunately why I am writing this today.) Why are so many Mac users 'convinced' that malware is not a problem for them? (or maybe, more likely, they have been convinced...) This concerns me because these people make blanket statements like, 'I don't worry about viruses, botnets, and other attacks because I use a Mac'. Ugh...
These people seem to forget that many attacks are not OS level but application (PDF anyone?) and protocol level (MiTM?) and that they could still be vulnerable to these attacks, not to mention the grossly overwhelming confidence they have in their unstoppable OS! Worse yet, they are being fed this information (about not being vulnerable to attacks) from various 'legitimate' sources like print and online media outlets.
The MacWorld 2010 issue states some of the following within its pages (simplified to some degree for my purpose here - please feel free to pick up a copy and compare notes):
As you can see, it is no wonder the general Mac population is overly confident at this point. My advice. Be on the lookout, be smart, and don't wait for the impact before putting your seatbelt on...
I will leave you with one more quote overheard by a co-worker of mine in the past couple weeks at an Apple Store from an "Apple Genius":
"...go ahead and turn off wireless security. It just complicates things and is not really necessary. Nobody can guess your SSID. Who would guess an SSID of JOHN?"
LOL! Guess... Ya, that's what we do... Guess! Just Genius! Poor users,... poor, poor, users...
Did the title of this blog entry throw you off a bit? It will all be explained shortly.
In the InfoSec industry, we have one problem we have yet to solve with technical controls, 'the user'. This being a blog entry and not a book (or series of books), I will only address one of my major concerns with 'the user' here.
Today's Problem = Password Reset Questions
Assuming my experience with users and user accounts is the same as the majority of other people in the InfoSec and SysAdmin space, I think we can all relate with the situation where a user forgets their password. At this point, depending on the system in use, they often have a few options.
Quite often, many websites offer self-service password reset options. This is very common, especially since many of the sites requiring login are completely unattended, unstaffed, and unfunded (such as blogs and forums). Many other sites (that are attended) also offer self-service password reset online such as financial institutions. Additionally, locally installed software requiring local authentication can also provide this 'feature' as well, such as seen in the Quickbooks accounting software.
A very common form of self-service password reset is the user being required to answer a question or multiple questions correctly. These are often questions they selected and provided answers for at account signup. These questions are quite often provided to the user in a dropdown box and requires them to select the questions they would like to answer at a later time should password reset become necessary. Sometimes these questions are quite simple and sometimes they are more difficult to remember but they always have to do with the individual. Here are a few sample questions:
Now, here is the concern. It is actually, in most cases, very easy to get all of the password reset questions for an individual. In many cases, this info is public domain, available on facebook/Linked-in/other, or publicly observable. So, why hack a password if I can just reset an account? This is an even larger concern when you consider that even data that cannot be found is often guessable since the answers can often fit into various password cracking dictionaries like: names, numbers, months, etc. This opens up the potential for a combined attack using knowledge and brute-force if necessary although Facebook is all you usually need to succeed in a reset. Now, to further simplify the reset process, you need to consider one more issue. Users are lazy. This means they are going to select the easiest questions to answer, every single time! So forget the crazy questions, you often don't need the answer to those. Pets and mothers maiden name is enough. Ok, let's make matters even worse. Most users use the same password everywhere, and if they can, they also use the same user-id. This means we can get into the easiest resettable site the user has an account at and potentially leverage that to get the password for other sites. (This depends on the outcome of the reset process: exposing the current password, emailing the password, etc)
So, what can a user do about this? The first thing they should do about this is to NEVER PROVIDE REAL TRUTHFUL ANSWERS TO PASSWORD RESET QUESTIONS! Additionally, to avoid brute force attacks, don't even provide data that fits the description. Just because a question asks for a NAME, doesn't mean you have to provide one - it is not like they are going to check your answer… So, if you are asked for your mother's maiden name you can choose to answer: Apkjhdfrcjd. And why not? It is not going to be in a dictionary and most certainly not in any of your records online or in print. The trick when using this method is to ensure you keep the information for the day you need a reset. A physical printout hidden or locked away or a password manager are common places to keep this info until you need it.
NOTE: You may, in some cases use this data if you call into a site for a reset as with sites like XMRadio. So, beware that you may end up with really confused people on the other end of the line when you tell them your mothers maiden name is Apkjhdfrcjd :)
Additionally, you most likely don't need to actually give different answers to all sites, simply come up with a list of answers you will use for all password reset responses and use those for everything. When you combine 10-digit random strings and the fact that you need to get multiple correct answers, you have a very secure system. When coming up with the answers, don't feel you need to write every question possible down verbatim. Actually, you will start to see a pattern emerge that illustrates the need for only a few answers. Here is a list of questions that should provide you more that enough 'seed-data' for this process and methodology to be successful.
From here, you can see that if you are asked either "What was your first child's first name?" or "What was your best friends first name when you were in 3rd grade?", they can both be answered with your response to "A First Name?" from above.
If you would like to auto-generate this list of answers above to begin securing your password reset process, feel free to use the tool at http://www.priveon.com/external/dbjbh.html
Here is a perfect example of how Social Networking and their relatively open APIs allow for easily combining personal data in a way most people don't expect. (Although they should) PleaseRobMe.com has leveraged twitter and the information many people provide from sites like foursquare.com to inform the world when you are not home. Better yet, where you are right now. You can easily see how someone who wants to take anything and everything from your home could do this quite easily simply by waiting for you to tell the world where you are right now!
The way this works is that someone signs up for a twitter account and a foursquare account (and link the 2 accounts). Now just load the foursquare application on your smartphone and voila! Now you can automagically send out tweets telling everyone where you are. Oh, and as you start to provide information to foursquare, such as naming locations, items like 'your house' becomes easy to see by a criminal. Oh, and don't worry... If you don't name your house and mark its location... your friends will for you!
Take this one step further and stop worrying about your personal belongings. What about you? What about a stalker? As I said earlier in the title... Twitter Mashup FTW!
Multiple CSA vulnerabilities were disclosed yesterday by Cisco PSIRT including:
CSA 6.0 directory traversal vulnerability
CSA 5.2 Denial of Service (DoS) vulnerability
CSA MC directory traversal and SQL injection vulnerabilities
CSA 5.2 Agent for Linux Denial of Service vulnerability (This includes standalone agents on various Cisco Voice servers)
Directory Traversal Vulnerability
SQL Injection Vulnerability
Denial of Service Vulnerability
Please continue to check the PriveonLabs blog for details and additional mitigation procedures.