TechEd 2009 SIA323: What Developers Can Do Today to Better Protect Their Applications from Malicious Attack

May 12, 2009 – 9:24 pm
Even though I needed to spend Day 2 in my hotel room finishing a deliverable I have to tell you from my experience with Day 1 (05/11/09), Microsoft has definitely put on a great conference.  The talks that I’ve been to have been nothing short of top-notch and I am looking forward to heading back there for Day 3! If you’re around on Thursday, swing by and check out my session in room 409 at 2:45-4:00 pm and introduce yourself, I’d love to meet you:

SIA323: The Microsoft Security Development Lifecycle (SDL) is the industry-leading software security assurance process. The Microsoft SDL became mandatory at Microsoft in 2004, and since then it has helped Microsoft make significant security and privacy improvements in flagship products such as Windows Vista and Microsoft SQL Server. Customers who have also adopted the Microsoft SDL internally within their own software development lifecycles (SDLC) have experienced similar successes. What about legacy applications? What about those applications that were not built using the guidance, tools, and best-practices from the Microsoft SDL? Or what about applications developed prior to the inception of the Microsoft SDL? What are the top effective and easily implementable things developers can do today to start protecting their customers and making their applications more resilient to malicious attack? Learn about common application vulnerabilities, how malicious users (or hackers) might exploit those vulnerabilities, and what developers can do today with the guidance, tools, and best-practices from the Microsoft SDL to better protect their applications from malicious attack.

See you there!

–Kevin

By Kevin Lam (IMPACTA) | Posted in Security | Leave a Comment

Impacta LLC and Microsoft Corporation work together in February 2009 to protect online customers

April 27, 2009 – 9:20 am

It’s a little late, but once again I am happy to announce that Impacta was acknowledged by Microsoft for helping Microsoft protect their customers by responsibly reporting vulnerabilities for the month of February 2009.

Check out Microsoft’s security researcher acknowledgement page for more information. 

–Kevin

By Kevin Lam (IMPACTA) | Posted in News, Security | Leave a Comment

Twitter Worm: How It Could Have Been Prevented

April 14, 2009 – 9:54 am

No doubt you may have already heard about the worm that hit the Twitter service over the weekend that affected 10,000+ tweets as reported on Twitter’s blog. According to the Puget Sound Business Journal, 17-year-old Michael “Mikeyy” Mooney from StalkDaily admitted to originating the attack.  

How could something like have been prevented? More important, how could you prevent something like this from happening to you? From what I can tell, the attack is based on what’s known as a cross-site scripting (XSS) vulnerability. Cross-site scripting vulnerabilities happen to be the most common Web-based vulnerability and relies on the fact that Web-sites and services (like Twitter) read data from un-trusted sources and then embed that data in Web responses. If that untrusted contains malicious script then any user’s Web browser reading the Web reponse containing the malicious script will be affected, or in Twitter’s case infected.

One way to visualize cross-site scripting attacks is say someone gave you (let’s say your name is Bob) a package and asked you to store that package and give it to the next person who comes to your door.  Inside the package is a bomb (unbeknown to you), and so when someone new comes to your door and you give them that package. That new person will think “Hey I trust Bob, I’ll go ahead and open the package” and … boom! From the perspective of the victim, you were the one who attacked them, and not that unsavory character who asked you to store the package in the first place!  This is how a variant of cross-site scripting called persistent cross-site scripting works, and I suspect what happened to Twitter.

To remediate cross-site scripting vulnerabilities you’ll need to encode any potentially any untrusted data prior to embedding it in Web responses. To easily encode data you can use the Microsoft Anti-Cross Site Scripting Library which while at Microsoft I helped release v1.0 (deprecated) and v1.5. The current version of that library is up to v3.0 beta right now. I haven’t played around with v3.0, but the idea behind encoding remains the same: encoding takes ‘potentially executable data’ and transforms it into ‘non-executable data’. Or if we go back to our exploding package example, encoding has the effect of defusing the bomb before giving it to someone. 

So to prevent something like what happened to Twitter from happening to you, follow this rule: if you read data from an un-trusted source (such as users, other services, etc.) and embed that data in Web responses, encode it first.  Here’s a tutorial I wrote on using the Microsoft Anti-Cross Site Scripting library that will help.

Good luck, and if you have any questions on preventing cross-site scripting vulnerabilities feel free to drop an email to info@impactalabs.com.

–Kevin

BTW: I don’t profess or wish to tell anyone what to do (or in this case what not to do), but why on earth would you want to claim credit for this worm? The days of hacking a major site/company/application, claiming credit for it and instantly landing a nice cushy job are long gone. Michael Mooney probably had good intentions at heart, but he will be lucky if he gets away without having serious charges pressed against him.

By Kevin Lam (IMPACTA) | Posted in Security | Comments (2)

Top Developer Security Pet Peeves, What Are Yours?

February 17, 2009 – 1:17 am

Hey everyone, looks like I’ll get the fabulous opportunity of presenting at this upcoming Microsoft TechEd 2009North America developer track. The topic that I’ll be presenting on is tentatively on is the top things developers can do today to make their applications more secure and trustworthy. There will be demonstrations of today’s most common attack scenarios, mitigations that can be implemented easily and effectively and lots of interesting discussion!

So the question I have for all my readers is this: what are some of the most frustrating things that you find as a developer about security? Do current tools produce too many false positives, is the current guidance on developer security too thin or too thick – what are the top 1-3 security things that frustrate you and/or prevent you from easily integrating security into your normal developer activities?  If you would rather email, send your top 3 to info@impactalabs.com. In a couple weeks, I’ll tally up the results and post them on this blog.

I have my own opinions and experiences, but I thought I would start with the community at large so that during this presentation we can really get to the heart of the problem. More information about my session to come as it becomes available. Looking forward to hearing your thoughts, and if you’re at the conference drop on in, I would love to meet you!

–Kevin

By Kevin Lam (IMPACTA) | Posted in Security | Comments (2)

Stop Listening to Security People: Focus On The Why Rather Than The What

February 11, 2009 – 1:36 pm

stoplisteningtosecuritypeople3There, I said it: stop listening to information security people. Before you fire your security vendors, disable those perimeter defenses and toss your security development processes to the fire there’s more to this story you should know.

On the front page of MSN.com this morning, there was an article entitled “Stop Listening to Suze Orman” and it reminded me of some of the cardinal lessons I learned in a past life as a semi-successful amateur day-trader (hey, I had to bootstrap my security company Impacta some way :P). For those of you who don’t know about Suze Orman, she has a show on television were people call in, explain their financial problems (stocks, real estate, retirement planning, etc.) and she offers her perspective (<– keyword, remember this for later) to callers. The MSN.com article knit picks at some of Orman’s general trading strategies and former stock picks, but if you boil this article down to the bone there’s a very important lesson to be learned here that can be also be applied to information security.

The mistake I made as a day-trader when I was first starting out was to listen to trading/investment experts. If Joe Expert said buy stock X, I would buy stock X. If that same expert said short stock Y, I would short stock Y. I soon realized that doing this was a sure path to financial disaster. First, trading/investment experts are indeed experts in their respective fields and they deserve all the successes they’ve had. However, there’s one field that they can’t be experts at: you. You see, those experts have much larger bank rolls, higher risk tolerances and much more powerful trading platforms that normal traders/investors won’t. So while they can provide a perspective that makes sense for their own situation (i.e., buy stock X), that perspective may not necessarily be the right one for you. The day that I changed my strategy and used advice from experts as a single input amongst others (my personal risk tolerances, my personal financial goals, my own research, etc.)  to make my own decisions, and not just following their advice blindly, significant successes soon followed (and a lot of them).

I suspect the same lesson could be applied to the information security industry. Take this common scenario where organizations hire security vendors who run tools and do all sorts of weird and wonderful things to uncover  all sorts of information security nasties. A report comes in and organizations blindly follow the remediation steps listed (similar to investors blindly following ‘expert’ advice). Bad idea and here’s why: those reports are based on technical findings and from the perspective of someone who is independent from your business (someone who does not understand your business). For assessing risk that’s a good thing, but when it comes to mitigating risk that’s not always the case. That technical risk perspective may not align well your particular business objectives. Often it does, but in the instances where it doesn’t bad things happen. Applications get crippled due to incompatibilities with recommended patches, money gets wasted on addressing vulnerabilities in areas of the business with lower business priority but high security priority and so on. Potential revenue is lost and the friction between security and every other business function is perpetuated.

Now, organizations are 100% entitled to address risk in whatever fashion they please. That’s not for me to say otherwise. However, what I’ve personally found useful when helping my customers address security risks to help them make better business decisions is to focus on the WHY rather than the WHAT.  When you’re presented with a slew of security vulnerabilities that need to be addressed and you don’t have infinite resources to address them all, ask yourself these helpful questions:

  1. Why does this vulnerability translate to a business risk?
  2. Why does this impacta (<– sorry, slip on my part :P) the business?

Here’s an example, say you get a report finding that says that you have a potential buffer overflow condition in your application.  That’s the what, that you have a buffer overflow condition.  Well buffer overflows are bad right?  We should spend resources to fix it.  Hold on, let’s consider the why.

  1. Why does this vulnerability translate to a business risk?: If a malicious user is able to exploit this buffer overflow, they could gain access to customer data (confidentiality), modify that data (integrity) or degrade the application to legitimate users (availability).
  2. Why does this impact the business?: If a malicious user was able to do the above actions, that could degrade our customers confidence with our service. We could also be subject to fines for not having sufficient security controls. All translates to loss of revenue.

Turns out in our example that the technical risk aligned well with the business risk, but asking questions like the above can help you better ensure that that alignment is consistently there. This small perspective shift I’ve found has been a very useful and powerful tool, and has helped me be more effective in security, trading and other areas.

Just as with investing and trading, you know you best.  Security is just one facet of your business and not the entire story. So in my experience, when you fold in business factors (the ‘why’) when addressing information security issues (the ‘what’), the better off you’ll be. What are some of the techniques that have helped you?

 –Kevin

By Kevin Lam (IMPACTA) | Posted in Risk Management, Security | Comments (19)

Impacta LLC and Microsoft Corporation work together in January 2009 to protect online customers

February 11, 2009 – 10:58 am

Once again, I am proud to announce that Impacta’s security researchers got recognized again by Microsoft Corporation for helping Microsoft make their online services safer by finding and reporting security vulnerabilities for the month of January 2009.  Impacta has been continually recognized by Microsoft month over month since 2007, and we look forward to continuing our work with Microsoft in 2009.

See Microsoft’s online security researcher acknowledgement page for more information.

–Kevin

By Kevin Lam (IMPACTA) | Posted in News | Comments (1)

The Dangers of Online Banking: How to Separate the Wheat from the Chaff

February 3, 2009 – 1:13 pm

dangersofonlinebankingscreenshotI opened up my Web browser this morning and on the front page of MSN.com (yes, yes … I confess my default homepage is still set to MSN) was this article about the dangers of online banking. The article was pretty well written, and it brought to light some very practical things people can do to better protect themselves from online threats later in the article. Being in the business of professionally assessing the security of all things online, I’ll be the first to admit that there are indeed risks to online banking (trust me on this one >:P). However, how this article came to that conclusion is what I found a little misleading, and if we go back to our framework for thinking about security in terms of people, process and technology I think there’s a very simple and valuable lesson here on how to quickly make sense of the information (good and bad) that we’re fed about information security. If you’re a home user, it might help you not get suckered into buying and wasting money on some ‘miracle security product’ out of fear, uncertainty and doubt (FUD), or if you’re a CIO, CSO, security manager or otherwise, maybe it will help you not get duped by shady security vendors. Whatever your case may be, I hope this helps.

Onto the article. The position of the article is that online banking can be dangerous, and stories about users get their accounts compromised are discussed to set the stage for further discusion. Here is an article snippet which describes how Joe Lopez’s bank account was compromised and temporarily had to the tune of $90k stolen from it:

What he didn’t realize were the risks (of online banking). A malicious virus had infected his computer and, in a matter of minutes, captured his user name and password — allowing a hacker to transfer $90,348 to a rogue overseas account.

Did you catch it? Did you see what was wrong with the above? If not, see if you can see the problem with this next article snippet which describes another victim named  Mia Joswick who fell prey to a phishing scheme that was impersonating her bank and on top of getting her account compromised, also had her identity compromised (since her password was her social security number):

Mia Jozwick, a student at Wagner College in New York City, was duped by a “phishing” e-mail made to look like a message from her bank. Thinking it was an important financial notification, Jozwick responded by firing off her user name and password; she learned it was a scam only after someone emptied her account.

Hopefully you caught the problem that time. If not, read on.

Here’s what I think is wrong with parts of this article and the way it concludes that online banking is dangerous. Let’s concede for a moment and assume that yes, online banking is indeed dangerous, and look at why online banking would be considered dangerous. For something to be dangerous (or insecure), usually this means that there is some potential for loss (risk), and that the controls implemented to reduce that risk will fail in some fashion. In other words, if you can map a potential for loss (risk) in some system, to a failure in a control for that system caused by some threat agent (or hazard) that causes the loss, then you can reasonably say that using that system poses unmitigated risks or is ‘dangerous’. So for online banking to be dangerous, that means one or more control within the online banking application has to improperly fail. We can further organize this thought pattern and say that some control within the online banking application failed in one or more of the following categories:

  • People
  • Process
  • Technology

Let’s first start with poor Joe. What was the cause of his loss, or why did it happen? According to the article, it was a computer virus that was able to capture his credentials and shuttle them off to some unsavory individual who then stole his money.  Let’s work backwards a little bit. The threat agent (the cause of the loss) here in this case was technology-based (a computer virus) and the possible controls that could have reduced the risk of having Joe’s credentials stolen were:

  • People: Education not to install untrusted executables/binaries
  • Process: n/a
  • Technology: Antivirus program

Clearly there was a failure of controls on the technology and the people side since either one of these would have prevented Joe’s computer from getting infected. But let me ask you this: do these controls exist on Joe’s side, or the online banking application’s side?  The answer is Joe’s. The fact that a malicious user was able to use those credentials to steal Joe’s money is a secondary effect of the controls on Joe’s side (not the online banking application) failing. Since no control for the online banking application failed in Joe’s case, it’s unreasonable to conclude that the online banking application is dangerous to use.

Now for Mia. Same thought pattern as before. The controls that failed in her case were:

  • People: Education not to trust emails claiming to be her bank
  • Process: Validating the authenticity of the email
  • Technology: Anti-phishing software (browser, etc.)

 Again, either one of these controls could have prevented her from giving up her bank user credentials, but where was the failure? On Mia’s side, or the online bank application’s side? The answer is Mia’s. So similar to Joe’s case, the online banking application cannot be attributed to this loss and labelling online banking as dangerous based on these anecdotes is unreasonable. 

You could argue that the point of the article was really trying to say that the Web makes doing online banking dangerous, but here’s the question I would ask: If you run a red light and get into an accident, do you blame bad judgement or do you blame the road (i.e., the Web)?

Before I end off, let me at least say that the point of this post was not to slam end-users (I am glad to hear that Joe and Mia were able to recover from their losses).  It was meant to be an opportunity to share with you my thought process, and how we can use the framework of thinking about security in terms of people, process and technology to separate fact from FUD, the wheat from the chaff if you will. What are your thoughts?

–Kevin

By Kevin Lam (IMPACTA) | Posted in Privacy, Risk Management, Security | Comments (14)

Impacta LLC and Microsoft Corporation work together in December 2008 to protect online customers

January 12, 2009 – 1:46 pm

Impacta’s security researchers gets recognized again by Microsoft Corporation for helping Microsoft make their online services safer by finding and reporting security vulnerabilities for the month of December 2008.  Impacta has been continually recognized by Microsoft month over month since 2007, and we look forward to continuing our work with Microsoft.

See Microsoft’s online security researcher acknowledgement page for more information.

–Kevin

By Kevin Lam (IMPACTA) | Posted in News | Leave a Comment

Effective Malicious Hacking: Another Case for People, Process, Technology (But Not in the Way You Would Think)

January 9, 2009 – 6:49 pm

My friend emailed me today and said that her company’s IT department was warning users about a phishing email that was circulating around supposedly from IKEA. (This by the way is an example of a great IT department: they don’t rely on just technology – people and process are also part of their security solution, kudos to them!)

Spam and phishing emails are so common these days that we tend not to be surprised anymore by it, let alone inspired by it.  This time was different though. When I heard about this I mentally blurted out in my mind  “how stupid, they (the bad guys) should have sent it a week ago when IKEA was having their year end sale. It would have been much more belieavable then!” This got me thinking.

It became clear to me that while ’good’ security requires a mixture of people, process and technology (i.e., defenders), ‘bad’ security (the stuff for effectively attacking systems/people) also requires a mix of people, process and technology (i.e, attackers). In other words, the success of an attacker or defender is dependent on their ability to exploit a weakness in the other’s strategy from the perspective of people, process and technology.

Let’s take the IKEA email as an example. The phisher’s strategy looked like this:

  • People: None.
  • Process:  Traditional, click on this link to login scheme …
  • Technology: Mass mailers, open mail relays

Now pit this strategy against my friend’s company IT department strategy:

  • People: Education about email-based phishing attacks
  • Process: Education on inspecting the provided login link to see if is legitimate
  • Technology: Spam and phishing filters

Technology versus technology, the phishers won because in this instance they were able to bypass the automated mail filters. However, the phishers lost because of process versus process. My friend’s company’s education on how to inspect links for authenticity was able to uncover the phishing scheme.  Even if the process side failed, then from a people versus people perspective my friend’s company would still win because it would be their education on email-based phishing versus essentially no strategy from the phisher.

Now consider what happens if the phisher’s strategy looked like this:

  • People: Send the email right after IKEA advertises on television or some major promotion to establish context.  Say “You may have seen our TV commercials’ya …”
  • Process: Inform the user that they can print some coupons for IKEA at some third party website that is partnering with IKEA for the holiday season. At that site provide a fake coupon image (or even a copied real one) that can be printed, and indicate that they can take this coupon to a store, or click this link to login redeem it online right now.
  • Technology: Mass mailers, open mail relays

We already know that the phishers can bypass the mail filters, so technology versus technology is out the door.  Here’s where it becomes interesting. Process versus process, the phisher has a better chance now, because they are not asking the reader to click on a link to login, just to go to some website to print out some coupons (who doesn’t love coupons?). My friends’s company may have only educated their employees on phishing attacks that want you to login by clicking some link. (I highly doubt that this is the case, since they seem to be so proactive about security already, but let’s pretend for now.) Sure the site wants you to click a link to login, but this is secondary action, maybe even call it a ’secondary phishing attack’.  People to people, the phisher now stands an even greater chance. Because they can reference something that someone may have seen on TV, what that does is it establishes context. Context leads to trust, whereas a random email out of the blue raises eyebrows.  It’s like an old girlfriend/boyfriend calling you out of the blue after 2-3 years of not talking.  Your first reaction is “what do you want?”, versus someone who you’ve seen last week “oh yeah, I remember you from last week …”.

So again, the success of an attacker or defender is dependent on their ability to exploit a weakness in the other’s strategy from the perspective of people, process and technology.  Now this might not be new to some of you, you might even be thinking “well duh” or “welcome to the 21st century Kevin”, but I think this kind of formalization and frame comparison (technology versus technology, person versus person, …) has significant benefits. It’s basically a more formal way of looking at multi-layered security strategies.

I for one am inspired.  What do you think?

 –Kevin

By Kevin Lam (IMPACTA) | Posted in Innovations Lab, Security | Comments (3)

A Tip for Getting the Assessing Network Security Book

January 9, 2009 – 3:38 pm
Assessing Network Security book by Kevin Lam, et al.

Assessing Network Security book by Kevin Lam, et al.

Hey everyone, I got several emails recently (in response to this blog posting) regarding how you can get a hold of a copy of Assessing Network Security (ISBN: 9780735620339, Microsoft Press) that myself, David LeBlanc and Ben Smith co-authored a few years back in 2004. 

  • Amazon. Amazon.com has some pretty great reviews of it, however I don’t think you can order it directly from Amazon.com anymore.  They provide some links to other resellers though.
  • Barnes and Noble. Says it’s out of stock, and also provide some links to resellers.
  • Bookpool.  Bookpool.com also says it’s out of stock as well.

Alright what now?  Here’s a little tip for getting this book if your company already has an account with Microsoft.  Ask your Microsoft account manager to order a couple copies for you internally via a tool called ‘msmarket’ (msmarket is called out publicly here on Microsoft.com, so I am not letting out some big internal secret). 

If you can get your hands on a copy, I hope you really enjoy it.  David, Ben and myself set out to write a book that was not your typical ‘hacking book’ based on exploits de jour and hacking tools, but rather on concepts, strategies and processes that are don’t expire or become irrelevant over time. While it may not be as exciting as other books on the ”lastest MS08-067 staging shellcode, exploit this, exploit that,” I think it definitely helped our readers tackle the problem of security in a more systematic, objective and sustainable way  in the long run. Looks like some of the reviewers on Amazon.com understood this vision of ours.

“The best pentesting book I’ve seen”

“An Excellent First Book on Pen Testing”

Anyways, I’ve got the writing bug again, so who knows I might get around to writing a second edition or another book one of these days. 

–Kevin

By Kevin Lam (IMPACTA) | Posted in Security | Comments (2)