Author Archives: rohyt
In past years I never attended the RSA conference; it always came across as too much of a vendor show to me. This year I didn’t think I would go, until rsnake convinced me otherwise. So I bought myself an Expo Only pass. I had a lot of fun, meeting old time buddies from Foundstone and Mandiant, a bunch of clients, and partners. But I had the most fun just watching the show on the Expo floor. Must have been 300 booths and a gazillion sales people swarming them with those annoying mics trying to outspeak each other like barkers outside a souvenir store at a tourist destination. Companies doing raffles at their booths – I’ve seen that, but arcade car racing games like those at Dave & Busters, security “Jeopardy” shows every hour being hosted by “slick” sales people, cheesy whack-a-fraudster, wannabe Houdinis showing off card tricks and free beer made the cut too. I wondered, do clients actually walk the floor to learn about new products? I think not. They do so for the free entertainment, adulation, and giveaways. Makes one wonder, are the RSA booths worth their price tag? The smallest, and furthest ones, which you would see if you were really looking for, are worth an arm and leg. VC money well spent? Oh what a circus it was!
- I would be very busy the week of Christmas, while IT security staff is probably operating at 20% normal strength. Not only is it the weakness in numbers, but also the holiday mood. How many of you are actually working full days? IDS logs – thats probably the last thing on your mind now that you have Guitar Hero III in the breakroom.
- I would get busy if I heard that a company was being acquired. From my experience, most companies put a freeze on all discretionary spending from the time a deal is announced untill it closes. Unfortunately, security is often thrown into that discretionary spending budget, making it easy on the bad guys for several months!
- If I really wanted to spend Christmas with my family, I would just come back another time and phish employees…that works irrespective of season.
Wishing you all a very Happy New Year! Stay safe.
Carnegie Mellon researchers presented a paper at the Anti-Phishing Work Group’s E-Crime Researchers Summit in October 2007. The results of the study indicated the following:
- Users learned more effectively when the training materials were presented after they fell for a phishing attack (embedded training), rather than when the training materials were simply emailed
- Users also retained more knowledge and transfered more knowledge about how to avoid phishing attacks when trained with embedded training
These are the underlying principles of PhishMe.com – Phish n’ Educate. PhishMe.com will facilitate the execution of mock phishing attacks against employees. Those that fall “victim” will be presented appropriate training materials.
Phishing is now recognized as a 2007 SANS Top 20 risk, and rightly so. What I was even more excited to see is SANS calling out the countermeasure correctly. They didn’t recommend deploying millions of dollars worth of technology to “catch” phishing attacks, but said “user awareness is a key defense. The most promising method of stopping spear phishing is continuous periodic awareness training for all users; this may even involve mock phishing attempts to test awareness”. As I said in a previous blog post , we are in total agreement with SANS on the efficacy of this countermeasure. In fact we are so in agreement that we have developed a solution (www.phishme.com) to do exactly that – run mock phishing attacks to test and measure employee awareness.
Now for the gimmicksmen. Qualys just made an interesting announcement – “Free security scan available for the new SANS Top 20“. I wonder how they are going to scan for phishing vulnerabilities.
The development of our phishing attack emulation service, to be hosted at www.phishme.com, is on target for a February 2008 release. We are in the midst of alpha testing at this time and hope to be ready for beta in January 2008. At that time, we will be opening up the service for free evaluation. If you are interested in being notified (via email) when the evaluation accounts become available please sign up at http://phishme.com/signup.php (we will not phish you ).
- The Phisherman
Till a couple of years ago, the input validation wand could be waved to solve almost any application security flaw – XSS, SQL Injection, Response Splitting, and the list goes on. That made it easy to become an application security consultant. If you could chant the “Input Validation” mantra you would be right most of the time. The advent of attacks like cross-site request forgery (which I prefer to call session riding) and session fixation, however, have made it difficult to pull off the input validation bluff.
Let’s talk about Cross Site Request Forgeries (XSRF) for starters. Corey Benninger explained the difference between the often confused XSS and XSRF in a previous blog post. The root cause of XSRF is the predicability of key HTTP requests that result in transactions with signifcant impacts.
E.g. If the HTTP request for transfering funds from one account to another is – http://www.hellobank.com/transfer.aspx?amt=1000&srcacct=1001829&srcaba=021000091&dstacct=9008990&dstaba=012000076
an attacker can lure a victim to visiting a web page, that in the “background” executes such a request to transfer funds from the victim’s bank account to that of the attackers. If the victim is logged in to his/her online bank then this transaction will execute successfully. The systemic issue is the predicability of the HTTP request. The way to thwart such an attack is to introduce a random element in every request to transfer funds, and more importantly verify that the random token has not been tampered with.
Now on to session fixation. The potential impact of exploitation of this vulnerability is often underestimated; for those that feel that this is a “Medium” or “Low” risk issue check out my BlackHat 2006 presentation. The fix for this issue is real simple – invalidate and re-issue user sessions after critical events like login, and switching from non-SSL to SSL on the website. It’s not input validation though.
I started thinking about this post while teaching my class at Carnegie Mellon University. One of the students came up to me after the web hacking class and asked me “What is the ONE thing I should take away from this session”. I said – “If it had to be ONE thing for application security it would still be Input Validation, but hopefully you didn’t just learn ONE thing”
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
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 “email@example.com” or “firstname.lastname@example.org“.
- 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
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!
Jack Germain interviewed me on the security implications of peer-to-peer file sharing programs. Excerpts from that interview can be found in this article that discusses the grilling of the LimeWire CEO by a congressional committee.
Personally, I stay away from P2P prgrams other than Skype voice chat. Yes, Skype voice conversations are peer-to-peer.
Security conscious developers, world over, look to the OWASP Top Ten as their do’s and dont’s guide. The importance of this list, to the application development and security communities, cannot be exaggerated. Have a look at these impressive statistics from one of Jeff Williams’ recent presentations:
Thus, a Top Ten vulnerability should be one that occurs most commonly and has a high potential impact; something that developers should be made aware of. Based on this premise, session fixation should bull doze into the OWASP Top Ten. Over 90% of all Java web applications that we have reviewed in the last couple of years have been susceptible to this attack. Combined with a little phishing, this attack can result in users’ accounts on vulnerable websites being hijacked. Let’s take a little detour and understand how this attack most often works.
• The attacker requests the home page of the vulnerable website
• In response the attacker’s browser is provided a jsessionid. Note: No authentication has occurred
• The attacker extracts the jsessionid from the response and constructs a legitimate URL with the jsessionid in it as follows:
https://www.vulnerablesite.com/login.jsp;jsessionid=<insert the extracted token here>
• The attacker then emails this link to a potential victim – a legitimate user of the website
• The victim does not find anything “phishy” with the URL. It actually points to the SSL website; no phony subdomains, suspicious IP addresses, illegible URL encoding, etc.
• The user clicks the link and is presented the login page. What the user doesn’t know is that his or her session is associated to the jsessionid in the clicked URL.
• The jsessionid continues to be associated with the user’s session post-login too.
• Now, the attacker can browse to any restricted page of the website by merely appending the jsessionid in question to the request. The application believes that the attacker is the victim and will readily provide the former access to the victim’s profile- think bank account.
Due to the default behavior of most Java application servers, web applications using the jsessionid for authorization, are often rendered vulnerable. Don’t get me wrong – I am not recommending against the use of jsessionid as an authorization token. I am only calling for the issue to be brought to the fore front by the foremost application security community – OWASP. Especially because it has an easy fix; developers should invalidate the session after critical events like login and re-issue a session ID.
<span lang="EN"><font size="2">session.invalidate(); session=request.getSession(true);</font></span>
Also, disable URL re-writing in web.xml.
Some may argue that session management is included in “A7 – Broken Authentication and Session Management” of the OWASP Top Ten. Yes, it is. However, just like cross site scripting and injection flaws got their own spots and were not clubbed under input validation, session fixation too demands the spotlight.