Building employee awareness to social engineering attacks, like Phishing, is clawing its way up the CISO’s priority ladder; and rightly so. But, what good are aware employees if your customers can be directly targeted by such attacks?

A month ago, monster.com had to deal with a phishing attack that targeted their clients and did so with some success. Security experts commented in this USAtoday article urging job seekers to expose minimal data and blaming monster.com for not enforcing strong passwords. I don’t want to undermine the soundness of those suggestions. However, I don’t believe they will solve the issue at hand. How about educating your clients and users about such threats? Now some of you may argue that these educational campaigns that include informative blurbs on the website don’t really work. Agreed. Is it time we adopted an innovative approach of emulating a phishing attack against our clients and instantly educating those that succumb by explaining what the exercise entailed and the do’s and dont’s? Such exercises have worked effectively when educating employees; that should be proof enough of their efficacy. And yes, I’m sure your legal counsel would shed a few drops of sweat if you suggested this exercise. But then there were a few who reacted in similar fashion when the concept of network pen testing was introduced.

Monster.com was not a one-off target. Here’s another company responding to a phishing attack against its clients:

---

From: ADPSecurity@adp.com [mailto:ADPSecurity@adp.com]
Sent: Friday, September 14, 2007 4:45 PM
To:
Subject: Fraudulent EmailsBeginning yesterday, certain ADP clients and other parties started receiving fraudulent e-mails that appear to be sent from ADP. They were not. If you receive these e-mails DO NOT OPEN, FORWARD, LAUNCH OR RESPOND TO THEM. IMMEDIATELY DELETE THEM. The e-mails and their attachments are malicious and could harm your computer. We believe they are attempting to compromise your data. WHAT YOU NEED TO KNOW: Here is what you should be on the lookout for:

• The “from:” address in these e-mails may have been spoofed to look like it is coming from ADP such as “emplservices292823@adp.com” or “adpcomplaintcenter@adp.com“.
• The subject line may read: “Agreement Update for [Your Company Name (Case id: ______)]” or “Complaint Update for [Company Name (Case id. #)]”.
• The e-mail may have an attachment named either Agreement.rtf or Agree.rtf or may instruct you to “download a copy of your complaint.”
• These attacks are sophisticated and you may receive other fraudulent e-mails. Please be careful not to open any suspicious attachments or to download any files.

ADP will continually update the information on its website to help you identify and avoid problems from these suspicious e-mails. You will be able to visit http://www.adp.com/about_fraudulentemail.asp for the latest information.

WHAT YOU NEED TO DO: If you received one of these suspicious e-mails do not open the attachment and do not provide any information of any kind. Delete the e-mail and any attachment immediately.

WHAT IS ADP DOING ABOUT THIS: ADP’s security team is working with law enforcement as well as outside experts to identify those responsible for this attack. If we identify any further steps needed to protect your computer, ADP will immediately post this information on our website.We appreciate your understanding as we work with law enforcement and you to resolve this matter.

---

Corporations have invested millions in security processes and technology. It’s time we focussed on the “people” factor. - Rohyt

1 comment

There was an interesting update yesterday about last month’s story about a Swedish security researcher who released the password and login information for 100+ embassy and government workers.

(I’m going to take some liberties summarizing this)

A Swedish researcher released 100+ passwords claiming he wanted to expose that the practice of using pop3, imap, etc shows a lack of user awareness. This also shows a lack of care and regard from the government institutions that permit inbound plain text authentication.

Some called for the lynching of this “hacker” while others were more curious about how the passwords were obtained. My initial off-the-cuff guess was a web exposure or a password list carelessly left online for google to cache.

How the passwords were really obtained proved to be much more interesting. In a blog posting yesterday, Dan Egerstad, revealed that he has been operating TOR exit nodes and sniffing passwords. I’m absolutely not surprised some people think that using TOR magically fixes all clear text protocols. What did surprise me is that government and embassy workers are using TOR. Are these workers really using TOR? It’s true that Tor is effective at masking the origination IP address from the destination address.

I think the REAL story here is that 100+ accounts have been compromised for months (maybe years) and that the real attackers have been using Tor to mask their origin IP address. Without Dan Egerstad exposing this; hackers, spies, (and who knows) could have gone on accessing these government email accounts unobstructed.

-higB

No comments

A recent survey of over 279 IT Executives indicated that the greatest security challenge they faced was building an effective security awareness program and encouraging their employees to embrace it.  Employees, albeit unaware, oblivious or unconcerned, continue to fall prey to conniving social engineers compromising sensitive data protected by millions of dollars worth of technology. The return on investment on building user awareness is apparent and no longer a hard sell for IT security staff. The real problem lies in building an effective program that actually changes the mindset of the employees.  In a society where 90% of recovering coronary bypass patients do not change their dietary and lifestyle habits, will an awareness program really change their attitude towards information security?

This year we conducted numerous social engineering exercises for Fortune 500 companies, whose success relies heavily on the protection of intellectual property. These exercises involved scripted telephone calls to the organization’s customer service departments and mass phishing emails targeting a randomly selected set of employees. The objective was to collect sensitive data; the results were astounding. At one organization, 627 of the 1000 people targeted by phishing emails (aimed at pilfering the employees’ corporate VPN credentials) succumbed to the attack and only 4 of the 373 that did not respond reported the issue to information security staff. It’s not so much those statistics that made the results astounding, but the fact that the organization had recently conducted user awareness workshops that addressed the threats posed by social engineers. So where did they go wrong? Are the information security personnel to blame for developing ineffective programs or the employees for their lack of following direction? I believe it’s a combination of both; but the information security staff must assume the onus of taking the initiative of developing innovative user awareness programs that make a lasting impression. The majority of the security awareness sessions I’ve attended whave been unstimulating affairs couching the do’s and don’ts of security. Another approach used involves mandatory computer based training (CBT) programs for employees.  At the end of the CBT session the employees had only improved their mouse-click speed. On the other hand, an approach I’ve found to be very successful entails sending out email to all employees (or to a representative sample of them) that mimics a true phishing attack aimed at garnering personal information. If the employees yield, they are immediately presented an informative message explaining the attack and redirected to the corporate awareness materials. This approach has proven to be very effective as the people who are most vulnerable are educated right away, and the next time a real phishing attack comes through, the emulation exercise will probably be the first thing that comes to the employee’s mind. One of our clients experienced a drop in the “hit rate” for such attacks from 67% to 4% over the course of three such phishing exercises!

-Rohyt

1 comment

There seems to be a problem with Cross-Site Request Forgeries. It seems like a large majority of people have this type of attack confused and I am not just talking about developers or end users. Security professionals still don’t know what this attack vector is (and I’m not talking about higB’s tongue-in-cheek Balls post.) The other week I heard a webinar by a major Web Application Firewall vendor claim his product protected apps from XSS and therefore it was the same as stopping CSRF. Granted, maybe the product can try to prevent both types of attacks, but it sure isn’t going to do it with the same types of checks. This was followed by a web application security meeting where the slides were trying to show a CSRF example and the presenter talked about checking for XSS. If the people in the security industry can’t even get this right, how are we suppose to educate developers and clients about this issue?

Let’s all start by renaming this attack. While I personally like the name ‘OMG you stole all my money without JavaScript’, the more generic ‘Session Riding’ probably works better for the long term. Yes it’s a subtle change, but it states what the attack is doing and drops the unnecessary ‘cross-site’. I’ve also found that many people think scripting is required for a Session Riding attack. While there’s no doubt that you’ll typically find JavaScript included in crafting a complex or obfuscated attack, it’s clearly not a requirement. In fact, it’s one reason these attacks can be so terrifying is that you can browse with all scripting disabled, no third party components, dropped privileges and a fully patched browsers, but a Session Riding attack could still work against you.

I’d recommend reading this PDF and the CSRF FAQ which both go into good deal on Session Riding attacks and countermeasures. But for a quick difference between the two, just look at what your typical attack payload for an XSS attack verses a CSRF attack would be.

XSS Attack Payload:
<script>alert(‘xss’)</script>

Session Riding Payload:
http://www.example.com/changepwd.jsp?newpwd=1234&confirm=1234
 
While you typically need to store/reflect your XSS payload on the site you’re going after, in the case of a Session Riding attack, you can store this URL on any site. In this example payload, we are trying to change the user’s password. JavaScript would not need to be required. The site can be doing whitelist input validation and it wouldn’t stop this attack.

There are plenty of ways to protect against these attacks (CAPTCHA, re-entering password, additional secure tokens, …). Some of the popular web application frameworks even have settings or plug-ins that can be dropped in to prevent Session Riding attacks. However, if we don’t understand the risk or report the threat, how can we help developers to implement this correctly into their applications?

-b3nn

2 comments