Priveon Labs Security Blog

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):

1. Your company doesn't have thumb drives - Solution Dropbox. (getdropbox.com) This lets you sync and access files from multiple machines (and iphone). Yes, this is true. There is a solution to not having USB sticks available at work, but maybe,... just maybe,... the corporate policy is trying to ensure the organization does not lose control of proprietary, confidential, or personal information. (In many cases, required by law and/or regulation to control...)
2. Don't worry about botnets. They furthermore comment on - one small botnet (http://www.macworld.com/5716) compromised by a trojan horse. They say that since a Mac needs to be first infected, which pretty much never happens, chances of it is extremely low…
3. Don't worry about it: virus and worms. No technical barrier is admitted on this point but no widespread malware for Macs soooo, until those attacks appear, there is little reason for the average user to invest in AV. Although, they do concede that if you work with corporate Windows people nearby, or use risky internet sites, then maybe it is worth the investment. LOL. Ummm, isn't the entire internet risky? Also, if Windows users are nearby...? Huh? So, basically... don't worry about Mac malware because the threat is low BUT cross platform malware is real and more of a threat? What?
4. Don't worry about bluetooth attacks. The odds are low of having an issue with this even with BlueTooth file sharing enabled because of the short range. Wait,... what? BlueTooth has a range of maybe 10m (30ft). So, a 30 ft radius (60ft diameter) from me effectively covers a StarBucks, a solid chunk of an airplane, etc.

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.

1. Stop using the system and forget about the account
2. Call a helpdesk for a password reset (more on this later)
3. Use a self-service password reset tool

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:

1. What is your mother's maiden name?
2. What is your father's first name? (Who's your daddy?)
3. What was your first pet's name?
4. What house number did you live at in the 1st grade?
5. What was your zip code in the 6th grade?
6. How many aunts and uncles do you have combined?
7. What size shoe do you wear?

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.

• A Full Name?
• A First Name?
• A Last Name?
• Other Name?
• A Location Name?
• A Street, City, or Country Name?
• A State (2-Letter)?
• A State (Name)?
• A Zip-Code?
• A Month Name?
• A Month Number?
• A Day of Month?
• A Year?
• A Phone Number?
• A 1-Digit Number?
• A 2-Digit Number?
• A 3-Digit Number?
• A 4-Digit Number?
• A 5-Digit Number?
• Other Not Above?

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
Good luck!

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)

Mitigation

Directory Traversal Vulnerability

• 5.1 - Not vulnerable
• 5.2 - Not vulnerable
• 6.0 - Upgrade to 6.0.1.132

SQL Injection Vulnerability

• 5.1 - Upgrade to 5.1.0.117
• 5.2 - Upgrade to 5.2.0.296
• 6.0 - Upgrade to 6.0.1.132

Denial of Service Vulnerability

• 5.1 - Upgrade to 5.1.0.117 (recommended release: not vulnerable)
• 5.2 - Upgrade to 5.2.0.296
• 6.0 - Upgrade to 6.0.1.132 (recommended release: not vulnerable)

Download:
http://tools.cisco.com/support/downloads/go/Redirect.x?mdfid=278065206

PSIRT Advisory:
http://www.cisco.com/warp/public/707/cisco-sa-20100217-csa.shtml

Please continue to check the PriveonLabs blog for details and additional mitigation procedures.