Endpoint

6/13/2016
11:20 AM
Jackson Shaw
Jackson Shaw
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

Self-Service Password Reset & Social Engineering: A Match Made In Hell

A sad tale of how hackers compromised a CEO's corporate account by trolling Facebook and LInkedin for answers to six common authentication questions. (And how to avoid that happening to you)

Recently, I was on a call with the CISO of a customer whose CEO’s account had been hacked. The CISO and his team were trying to understand how this had occurred, and, following a short investigation, we discovered that the hacker had been able to compromise the CEO’s password via the company’s software solution that enables end users to reset forgotten passwords.

After reviewing logs and other audit mechanisms, we determined that the hacker had used the solution’s self-service password reset (SSPR) capability to reset the CEO’s password. Once the password was reset, the hacker had free reign over the CEO’s account.

During an ensuing discussion about security policies for self-service password reset, the customer revealed they had implemented a Q&A-based SSPR, allowing SSPR based on correctly answering any one of three questions. During the call, it was mentioned that the CEO was somewhat of a celebrity and fairly well-known, so, with that information in hand, it seemed apparent that this was a classic example of a social engineering attack. The hacker guessed ‒ or knew ‒ the CEO’s email address and used that to access his SSPR Q&A profile. They then trolled Facebook, LinkedIn and other sources to find answers to his SSPR questions.

Physician, heal thyself!

A few days later, I had the opportunity to create an account on a third-party system that used SSPR for password reset, and --  based on my earlier conversation with the customer -- saw the questions I was asked to answer in a completely different light. They included:

  • What was the name of your first pet?
  • What was the name of the first school you attended?
  • In what city was your father born?
  • In what city was your mother born?
  • In what city did your parents meet?
  • What was your childhood nickname?

When I thought about how easy it would be for someone to hack my own SSPR Q&A via social engineering, I realized that, over the years, the answers to every one of these questions has appeared in a Facebook post or comment. If someone had access to my Facebook feed, they easily could figure out the answers and use them to gain access to my personal accounts. You can judge for yourself how easy or hard it would be for someone to find the answers to these questions via your own public Facebook or LinkedIn information.

These types of attacks are certainly on the rise. According to the recent 2016 Verizon Data Breach Digest, social tactics are being used in around 20 percent of confirmed data breaches, and when looking at the previous three years, the frequency increases to almost 30 percent of data breaches.

So, what was the outcome of my call with my customer’s CEO? Based on the fact that the company operates a worldwide business with thousands of employees and partners who access their systems, I offered the following advice:

  • Require more than one correct answer to the SSPR Q&A profile to reset a password.
  • Require more than three questions to be registered in the SSPR Q&A profile.
  • Pick a number of the out-of-the-box choices, but also require an end-user to register at least three “custom” questions and answers to which only they know the answer.
  • Employ multi-factor authentication (MFA) as one means to reset a password – especially for high-value or executive accounts.
  • Consider using step-up authentication to increase security in situations that include an end-user trying to reset a password outside of normal working hours, or perhaps trying to reset a password from an unknown location or device.
  • Utilize an out-of-band mechanism to deliver the password or reset code. For example, send the password or reset code to the end-user’s registered mobile phone.

How did I handle my own SSPR Q&A profile that I was asked to fill out a few days later? I answered some of the questions in an opposite fashion. For example, my first pet’s name became the name of my current pet, and I switched the birthplaces for my parents. I registered my mobile phone for password reset codes, something I thought particularly important after our recent customer call. 

Lastly, let me offer a final piece of advice: If you already have an SSPR profile set, check it. In my own case, I realized that my corporate Q&A profile was set in 2005, nearly 11 years ago. The answers to all those questions very easily could be guessed if someone had access to my Facebook profile. I’ve since changed a number of them, including my custom questions and answers, to make it harder for any hacker to use social engineering techniques to compromise my account.

Can anyone be 100 percent safe? Of course not. But the lesson here is that end users – at all levels --  should carefully evaluate their SSPR Q&A profiles in light of a social engineering attack. At the end of the day, SSPR Q&A profiles should not be the only mechanism for resetting a password. 

Related Content:

Find out how access keys will kill you before you kill the password when Black Hat USA returns to the fabulous Mandalay Bay in Las Vegas, Nevada July 30 - Aug. 4, 2016. Click here to register.

Jackson Shaw is vice president of product management for One Identity, the identity & access management (IAM) business of Quest Software. Prior to Quest, Jackson was an integral member of Microsoft's IAM product management team within the Windows server marketing group at ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
cstevo
50%
50%
cstevo,
User Rank: Apprentice
9/9/2016 | 2:53:08 PM
Well written and you must consider using a more modern solution
Thank you for the well written article-

Fortunately the trend is moving away from these "old-school" question/answer enrollment types of SSPR systems that have been around for 10+ years. Anyone considering use of a SSPR product should use one that employs newer more secure methods of user enrollment -as well as- a more secure underlying application architecture (Important!).


Another big thing always overlooked is the security of the SSPR application software itself. Most products don't use anything more than SSL for on-page web security, and most all of them require using domain administrative credentials inside the web application directly. Still others provide "Admin page" access within the same web application. Most all of these products will need to reside on a domain member server and have a local database containing all of the secure user enrollment data.

All of this is exploit waiting to happen and not the type of server you want to expose to the internet for remote user convenience. Savvy hackers will not bother with going thriugh the UI and guessing answers, they will instead attempt to exploit the web application or server itself using automation tools. Once the web appliction or server is compromised, there is usually a treasure trove of user enrollment data stored in a local SQL or mySQL database, as well as other domain intenral information.

There are good, secure SSPR products out there which help prevent these common exploit issues. You just need to put a bit deeper thought into your product selection because you'll find that most of them are not built securely and are only suitable for use inside a secure LAN. Good security for this type of product is going to go deeper than just the user-facing access mode itself.

 
steelaworkn
50%
50%
steelaworkn,
User Rank: Apprentice
6/19/2016 | 3:34:43 PM
Nothing is Simple these days
Regardless of the approach, password management is becoming more difficult.  With the security questions, I never answer the same thing twice.  The only thing I reuse is my usernames.  My passwords and everything else are different and never identical to the next.  

Those people associated with high profile companies should be vary savvy when joining social media sites.  The should neve divulge exploitable information.  Social Media sites are all about making lots of money.  Nothing should be considered secure.
theb0x
100%
0%
theb0x,
User Rank: Ninja
6/16/2016 | 10:45:06 AM
Re: Answers to security questions can be anything
My birthday is every day on Facebook.
theb0x
100%
0%
theb0x,
User Rank: Ninja
6/16/2016 | 10:12:46 AM
Security Through Obscurity
You failed to mention that the most effective method with setting SSPR questions is to provide answers to questions that are completely obscure and irrelevent to question itself. 

The SSPR system must also be well designed. For example, input of answers must allow full alphanumeric characters. This set must include both upper and lower case letters, punctuation marks, and symbols (such as @, &, and *, for example).

I would take this even a step further and include the entire ASCII table.

SSPR input validation must also be strictly throttled, monitored, include GEOIP filtering, and a CAPTCHA to help prevent the scripting of automated form submissions.

 

 

 
theb0x
100%
0%
theb0x,
User Rank: Ninja
6/16/2016 | 10:09:17 AM
Re: Answers to security questions can be anything
This does not take it far enough. RoverDog1! is still relivent to the question at hand.
Jackson_Shaw
50%
50%
Jackson_Shaw,
User Rank: Author
6/16/2016 | 9:40:39 AM
Re: Good point
Indeed. The moral of the story is you need to review this stuff regularly. For me, once in 10 years was clearly insufficient!
jastroff
100%
0%
jastroff,
User Rank: Strategist
6/14/2016 | 3:09:57 PM
Re: Answers to security questions can be anything
Good point >> There is no rule stating that you have to answer truthfully when entering your security questions.

Nor do you have to give the same answers all the time, but keeping track is difficult

And never give your birthdate out unless it has security -- all those people wishing you happy birthday on Facebook is a bit of a giveaway right there
jastroff
50%
50%
jastroff,
User Rank: Strategist
6/14/2016 | 3:09:47 PM
Re: Answers to security questions can be anything
Good point >> There is no rule stating that you have to answer truthfully when entering your security questions.

Nor do you have to give the same answers all the time, but keeping track is difficult

And never give your birthdate out unless it has security -- all those people wishing you happy birthday on Facebook is a bit of a giveaway right there
mnwvpn
50%
50%
mnwvpn,
User Rank: Apprentice
6/14/2016 | 9:30:23 AM
Answers to security questions can be anything
There is no rule stating that you have to answer truthfully when entering your security questions.  When asked for the name of your first pet for instance, you could answer RoverDog1! even though your first pet was Fido.  A password safe makes a convenient storage place for this information.
Whoopty
100%
0%
Whoopty,
User Rank: Ninja
6/14/2016 | 7:50:16 AM
Good point
I think one of the best points raised in this piece is that some security information we may have forgotten about is years or maybe even over a decade old. That's really problematic and is very difficult to change, because there's no way we have all kept track of our accounts on every service we picked up and dropped over the years.

Yet alone kept out security information tight. 

I often worry that some old service I was a part of will come back to haunt me with its lax passwords and still valid data. I may have moved on in terms of emails and passwords, but personal data not doubt still resides on some long dead accounts.
Windows 10 Security Questions Prove Easy for Attackers to Exploit
Kelly Sheridan, Staff Editor, Dark Reading,  12/5/2018
Starwood Breach Reaction Focuses on 4-Year Dwell
Curtis Franklin Jr., Senior Editor at Dark Reading,  12/5/2018
Symantec Intros USB Scanning Tool for ICS Operators
Jai Vijayan, Freelance writer,  12/5/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: I guess this answers the question: who's watching the watchers?
Current Issue
10 Best Practices That Could Reshape Your IT Security Department
This Dark Reading Tech Digest, explores ten best practices that could reshape IT security departments.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-3988
PUBLISHED: 2018-12-10
Signal Messenger for Android 4.24.8 may expose private information when using "disappearing messages." If a user uses the photo feature available in the "attach file" menu, then Signal will leave the picture in its own cache directory, which is available to any application on the...
CVE-2018-10008
PUBLISHED: 2018-12-10
A code execution vulnerability exists in the Stapler web framework used by Jenkins 2.153 and earlier, LTS 2.138.3 and earlier in stapler/core/src/main/java/org/kohsuke/stapler/MetaClass.java that allows attackers to invoke some methods on Java objects by accessing crafted URLs that were not intended...
CVE-2018-10008
PUBLISHED: 2018-12-10
An information exposure vulnerability exists in Jenkins 2.153 and earlier, LTS 2.138.3 and earlier in DirectoryBrowserSupport.java that allows attackers with the ability to control build output to browse the file system on agents running builds beyond the duration of the build using the workspace br...
CVE-2018-10008
PUBLISHED: 2018-12-10
A data modification vulnerability exists in Jenkins 2.153 and earlier, LTS 2.138.3 and earlier in User.java, IdStrategy.java that allows attackers to submit crafted user names that can cause an improper migration of user record storage formats, potentially preventing the victim from logging into Jen...
CVE-2018-10008
PUBLISHED: 2018-12-10
A denial of service vulnerability exists in Jenkins 2.153 and earlier, LTS 2.138.3 and earlier in CronTab.java that allows attackers with Overall/Read permission to have a request handling thread enter an infinite loop.