WikiLeaks DDoS and You

So I read a recent article yesterday about the WikiLeak supporters doing DDoS attacks on sites and it got me thinking.

Really thinking.

Consider this -- a group of hackers (and support them or not that is what they are), are bringing sites down at will on a moment's notice. No weeks of preparation, or coordinated touch and then attack. This is "hmmm...them" and boom that site is down. MasterCard, Visa, PayPal, etc etc. Boom. ______ Insert your company name here ______ BOOM.

Botnets are out there just twiddling thumbs. Some C&C (command & control, those "mothership" servers that command and control the bots at your parents' house and my uncles' house and those of the annoying admin assistants at work that forward you all those emails with smiling cats and angels and hearts and "you mean the world to me") servers are just sitting idle, a hair off the network. Infected machines are everywhere. Maybe mine right now. Maybe yours. Waiting. Some C&C comes online and says "Hit Greg's site" and voila it is down.

So why is WikiLeaks freaking me out a bit? I think WikiLeaks is a great thing. I really do. I may be wrong in thinking that, and to be honest I haven't researched the laws, but if you are dumb enough to leak out confidential stuff then it isn't their fault for publishing it. After the first few leaks, you'd think integrity and ethics would keep people from leaking info...ah but that isn't human nature, which dictates self-aggrandizing and soap boxes! Anyway, without more editorial, what is happening with WikiLeaks freaks me out because it shows that an organized group can take down big sites at will. If big sites are having problems, your mom and pop shop will too.

I have been soapboxing about devs learning about security and plugging holes. And the DDoS attacks show that even that won't stop them. You have to mess with DNS. And we all know how many people are good at messing with DNS and getting it all back in order a month later. It ain't the devs who can't close XSS holes that have been open since 1999! That's for sure.

So here are the pieces and you tell me how it affects you:

• Crippling attack


• lack of understanding of attack


• lack of resources to stop attack (expertise and time in-house or $$ for out-house)


• lack of understanding and resources to bring things back up


• lack of disaster recovery plan in most cases


• this attack brings your site's server down...oops is your email on there too?


• this attack is not stopped by anti-virus or strong development best practices


• this attack can happen to anyone at will and on a moment's notice

How do you rate in those? How about your company? Your friends? Your family? Your nation?

If a big huge attack has not been done yet, it is simply not yet time. The pieces are there. The code is there. The bots are there. It is just a matter of time before a set of things are brought down at once. Or that you or I say something that makes someone mad and boom...we are down.

I read how one guy did DNS changes that basically redirected the DDoS attacks back on the C&C server and it brought down the attack! ha! Classic and well done! But that is rare. You and I don't have that working for us. What can we do? I look forward to some comments and input on this one.

---

I am available for consultation or idea swapping on this sort of thing. In addition I train and speak to .NET developers about securing their web apps. Even though this sort of DDoS attack is not stopped through standard ASP.NET programming, there are lots of places where other attacks come through your apps. XSS and SQL Injection continue to run rampant. I can help you cut your risk of damaging attack significantly by doing a code review, training your developers or just helping you with next steps. Contact me at greg@bangordevelopers.com for more information.

Security in Apps Becoming Mainstream

Interesting article in DarkReading the other day about app security becoming part of the enterprise for software development.

It appears that folks are getting the first part of the solution, which is a nice start. Well, ok, we'll say the second part. The first part is really listening. Many of us aren't even there yet. The next step is to realize it needs to be part of your development process.

So here is what happens: you are in the dark, you hear about the issues for the first time and think "oh crap", you then panic and make all your developers get trained and stop 100 different things, they burn out and argue with you and it falls apart a bit. Take a quote from the article:

Sima also argues that too many firms ramp up their secure development programs too quickly. While training developers to write more secure code is a good thing, project managers should not go overboard, he says. Rather than try to tackle the top 10 or top 25 software issues, companies should instead take a small bite.

This is GREAT advice. As I have mentioned in previous posts, just learn about XSS and SQL Injection. Learn about them -- what they are, how they work, how to stop them. And then act on what you know. Taking care of those two alone will stop about 70% of all web attacks on your site.

Don't even tackle the top 10. Read up on them. Then tackle XSS and SQL Injection. Get your feet wet while you stop 70% of the attacks. Then move from there to CSRF, Authentication issues, Session issues and lots and lots of other things.

---

Just so you know, I can help you too. I am happy to work with you to train your .NET developers, or do code reviews or just consult with you on next steps. Drop me a note at greg@bangordevelopers.com and I will be happy to show you how easy it can all be.

Lots Going On

I'm back after a month hiatus or so. Figures I'd get too busy to blog right as so many juicy "write about me" sort of things happen. To be honest, I hope you've wondered what my take is. Not that I'm some security guru, or the man in the know, but because it means you are interested in this stuff and realize I am too, wanting to hear more about what I am seeing from the trenches.

Either way, here is my take on the last month, plus a peek at what is coming down the pike/pipe.

ASP.NET Oracle Thingy

So this was a biggie for .NET developers, ASP.NET developers in particular. As you likely know by now, it had nothing to do with Oracle Corporation or any of their technology. I won't explain what it was, since others have done better than I ever could. The vulnerability hit the internet blog posts mid-September and a fix was in place soon after. Microsoft ranked it as a big deal, though my first glance at it was no big deal. I still think they made it a bigger deal than it needed to be, but honestly it was refreshing to see such movement and activity on it. So why didn't I think it was a big deal? It was something that would take some time to exploit. Sure, the payloads of web.config files and all that would be worth it, but it takes quite a bit of exploit attempts to get the thing to work.

Now, to play the other side of things, which I enjoy doing as well, I REALLY hope you have applied the patch Microsoft gave you for your servers! My lack of whizbang about the issue doesn't mean I find it something to ignore. In fact in this case it is the opposite. The noise and commotion over this vulnerability makes hackers go "ooooh, pretty lights..." and head TOWARDS the issue. If they weren't trying it before, they sure are now. I have no formal study-borne proof of my assertion, but I know human nature. Didn't it cross your mind just a little as to whether YOU could execute it? I did mine. I thought it would be cool to write a routine that ran through some stuff and tried it over and over, even if only on my localhost. The truly bad guys/gals are too. And for some reason this exploit seems accessible to novices...it isn't all complicated I guess.

Anyway, PATCH YOUR SERVERS if you haven't already.

Lots Of Us In The News

Ok. So not me and likely not you. But we have to understand that though it was "them", "thems is us". How close are you or me from being a negative headline? In the last month news broke about healthcare data compromised, bank accounts broken into, Twitter hacked using onMouseOver javascript to send you to your favorite porn site faster, Twitter had a password-stealing phishing scam hit many people including CNN anchor Rick Sanchez (though it was a rather amusing hack), Facebook had at least one notable issue, and the SCADA attack showed us how subtle, intense and intelligent pockets of the hacker community are. The SCADA one in particular causes me anxiety. Facebook, Twitter, etc...close your holes already and adjust with the zillions of people who are on your systems. Not that these were avoidable in every case, but keep being diligent on closing holes. If you are popular then you are a huge target.

The SCADA one, however is different. Getting people to download a piece of software silently by just visiting a website, having your machine attack a single system in a concentrated effort, knocking that system down and still not being sure who attacked it...that to me is scary. Now, granted, where did it all start? Getting people to download software. They can either be silly enough to just surf to random sites where the software sits, or it is a good site that they go to that is silly enough to not close its holes. Again, Cross-Site Scripting and SQL Injection can really put the hurt on and allow lots of other attacks get the foothold they need to go forward.

Looking Forward

I don't like to look too far forward in this field. It is a lot harder to predict than general technology or programming. But this is so clear and getting clearer every day. What is happening is that hackers are looking more at the application layer and developers are lagging more than ever. As we educate the good guys, we point out our flaws to the bad guys. And frankly, they have more to gain in attacking than we do in defending. Defense costs money and if you do it right you have nothing to show for it. "Hey boss! I need a raise! Nothing has hit us for a year!" Uh, yeah. Unfortunately, if nothing has hit you, it could be you are really good at defending or that hackers just haven't given you the time of day yet.

I am predicting a higher use of CSRF and that is coming to pass. I am also predicting that we are just seeing the tip of the iceberg on successful, intelligent attacks. SCADA, though somewhat complicated and highly organized, wasn't all that difficult. We still have the easy holes to plug. Once we plug those, and I don't know that we ever will completely, they will be a few steps ahead of us, ready and waiting with more complex attacks. I'm a glass half full guy, really I am, but the state of software security has me wondering WHEN not IF a large full-scale attack will wipe out the internet for an extended period. The bad guys are already taking our money from our accounts, stealing data from our companies, attacking our systems and they already are doing it rather silently. They are growing in understanding and savvy. We aren't. We aren't. We aren't.

Our bosses still expect us to make our sites 100% secure (impossible), and they are not training the rank and file developer on security. "You are the security folks. I count on YOU." But we can't follow every developer and do code reviews...it isn't feasible. We are still building crappy software and sites full of holes. And if you aren't even sure what the holes are in your code, shame on you but you aren't alone. Let me know if I can help. I am willing to educate you, point you to awesome training materials and sites, look at your code, build something for you. It really is time to get off the sidelines.

CSRF On The Rise

If you have heard any of my talks in 2010 you know how scary CSRF (Cross-Site Request Forgery) is and how I think it will be taking off and going from #5 in the OWASP Top 10 to #3 (hard to top SQL Injection and XSS at #1 and #2). It hasn't gotten a lot of press, and there hasn't been a ton of action on that front by the bad guys...yet.

But this week an article in DarkReading about CSRF came out that shows it is starting to increase. My comment at the bottom of the article should sound familiar to those of you watching this blog (I think there are 4 or 5 of you out there, right? ) -- the press and the noise is still about patching and server-side, network-facing solutions. They are band-aids and stitches fixing holes that will continue and continue until developers learn to code more securely.

"Blah blah blah" some of you may be saying. "Same old same old. Show us something more, Greg." Well, if you thought that, or said it out loud, I have to ask "Are you actively coding against SQL Injection and Cross-site Scripting?" If you are, and my spiel sounds old, then it is time to move on away from here. And CONGRATULATIONS, Grasshopper! You have become a better developer and that is a success for us both in my book!

For the rest of you, please dig in. Read my previous posts and go to sites like OWASP and ha.ckers.org and see how to code against SQL Injection and Cross-site scripting. These two things alone will help us all.

So what about CSRF? What can I do about it? The short answer is that the hole is plugged at the destination of the attack, and that is by validating all actionable requests thoroughly. Huh? I will do more posts about CSRF, what it is, how it works, but in general it is that you have to make sure requests come from someone you know already, that has logged in and has a specific signature or footprint so you know every request that comes from that person. Analogy time -- if someone came to your door, 6 ft and blonde, and hands you their username and password, then you can generate a ticket and session for them. If someone 5' and brunette comes to the door with the first person's ticket, is it the first person? Obviously not, but our web servers only look at the ticket! If you have the ticket you MUST be the right person. Ouch! This is what makes CSRF work, executing an action on someone else's behalf. So the solution is to look for the 6ft blonde on each request using that ticket. For you .NET folks that solution is via the ViewStateUserKey. ViewStateUserKey can be set to the session id of the current user and that will be enough to show the server it really is the right person. The hacker won't have viewstate in a link, and if they try to create a whole form to do the work it won't have the current session in it. Ahhh...much better! (Side note about it not being perfect found in this article.)

So now maybe I will have to harp on proper CSRF coding as well as SQLi and XSS...

Great Training

I just took this course, in order to prepare for the GSSP-.NET certification and they've updated it to be language agnostic and cover what is really necessary and important for web developers to know. It focuses on the OWASP Top 10 you hear me talk about, etc. (This is a nice change from what was really a B or C+ course) You need to take this course if you build web apps -- .NET, Java, PHP, whatever. Take this course.

http://www.sans.org/vlive/details.php?nid=21094