It’s been a while since the last post, but I am happy to report that things are really cranking behind the scenes here at Impacta. We’ll have some exciting service/product releases coming up soon that will really help our customers reduce their online risk. You can follow us on Twitter if you have not already done so at:
–Kevin
I was following some of the news stories on television (mostly pieces about Michael Jackson memorial service, and the shape of the economy, etc.) when a news story broke out that the websites for the United States White House, several other government sites and the NASDAQ where under cyber attack! Allegedly the attacks were originating from Northern Korea. The news piece even had a guest cyber-security speaker, scary shots of Northern Korea, and the works!
Now I believe that homeland security is important, actually scratch that, very important, but in this case what really was the big deal? This may very well later turn into some more major, but for right now with what we know what’s the immediate risk and what is the impact from that risk? Compared to the other homeland security challenges we currently face (terrorism abroad, critical infrastructure attacks, global warming etc.) a public user temporarily not being able to access a Web site ranks pretty low in my view (if at all). The internal operations at the White House and the NASDAQ continued to operate normally, no confidential data (that they know of) was stolen or lost, etc. so what was the big deal again?
This is my personal opinion and experience only, but often we focus too heavily on the the what rather than the why. I previously wrote a post on how to prioritize risk (the why), which boiled down to:
Especially when it comes to issues in computer security, focusing on the risk first then the threats and vulnerabilities afterwards will do you wonders. It will save you money and plenty of grief in the long run. Good luck!
–Kevin
Impacta was once again recognized by Microsoft Corporation in the month of May 2009 for helping them to find vulnerabilities in their online services and protecting their customers through responsible reporting.
Check out Microsoft’s security researcher acknowledgement page for more information.
–Kevin
Once again, I am proud to announce that Impacta was recognized by Microsoft Corporation for helping them to find vulnerabilities in their online services and protecting their customers through responsible reporting for the month of April 2009.
Check out Microsoft’s security researcher acknowledgement page for more information.
–Kevin
Microsoft TechEd 2009 is now a wrap! My session took home some pretty high scores and from the looks of the evaluations so far at least within the top 10 in the security, identity and access tracks, possibly top 5! By this time next year, I am hopeful that one of the key preventative online risk technologies we’re developing over here on this side of the fence will be ready to unveil and I can’t think of any other better forum than Microsoft TechEd 2010 (New Orleans), so here’s hoping to us getting invited to speak again!
–Kevin
Not that ASLR is a brand new thing, but this was the first time that I’ve had to go head on against a defensive mechanism like this and it almost gave me a heart attack. Bad news for the real bad-guys, good news for the rest of us. Bravo, nice work Microsoft! Here’s what happened …
My presentation yesterday at Microsoft TechEd 2009 included a discussion about buffer overflows attack (essentially one of the most common ways malicious hackers compromise systems). So a couple hours before the presentation I decided to kick the presentation up a notch and write some shell code to demonstrate some pointer jumping. Mistake #1. Below is a snippet of the shellcode that I wrote against my Windows 2008 demo machine and therein was Mistake #2. Read on.
It’s simple shellcode that uses a series of calls to LoadLibraryA and WinExec to add an unauthorized user onto the exploited machine. Great, so I get it working in enough time to go and eat lunch, then come back to the speakers room to go through the presentation one more time about 45 minutes before the actual presentation. When I get to the buffer overflow demo part *fizzle* … my shellcode crashes! Try it again, same thing. When I loaded the exploit in a the debugger, turns out the after every restart of my demo box my offsets to kernel32!LoadLibraryA and kernel32!WinExec were bouncing all over the place.
At this point I am starting to panick a little and about ready to kick over the table in frustration when (not kidding here) I see Mark Russinovich (of SysInternals fame) sitting across the table from me and it dawned on me that it was Microsoft’s Address Space Layout Randomization (ASLR) which is a protection feature in Vista and Windows 2008 that was preventing my attack code from working! I eventually got the shellcode stable, the presentation went really well, without a hitch and the crowd was very happy. I guess here’s the message that Microsoft is sending to the bad guys with ASLR: ”Oh, so you want to exploit a Windows 2008 machine? Forget about it.” Again, nice work Microsoft!
–Kevin
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
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
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.
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
