Just a heads up that you want to be careful when changing web.config files around. Like you, I like to put .old or .bak or something on the end of files sometimes so it won’t be used by the system and so I have a backup in case I want to revert back to that version. One nice thing ASP.NET does for you is not allow .config files to be pulled up directly in a browser. It blocks requests for files ending in ".config". However, IIS/ASP.NET does not protect .old and .bak the same way. It will be served up unless you turn that extension off in other config files and IIS. There are your sql connection strings in plain sight (most of us don’t encrypt the connection string section in all cases like we should). Better to just make a local copy and make sure you don’t have any remnants, test files or backups in Production.
The first step in hacking a site is getting the layout and landscape. They will find your .txt files with code segments, your .old and .bak files, etc. Don't make it easy for them...keep that stuff off of your production servers, internet and intranet.
Wednesday, May 11, 2011
Thursday, February 17, 2011
BBC Sites Injected with Nasty IFRAME
An article in Dark Reading today tells about a nasty attack on two BBC sites that has an IFRAME injected onto the site that downloads nastiness to your computer, and only 20% of the anti-virus software packages catch it. OW!
Read the article
Key thing is injected. It almost makes it sound like BBC is a victim, doesn't it? "Hey did you read how the bad guys injected this nasty code into two BBC sites?" Folks, in a sense they ARE a victim, with an unwanted set of code put there by some 3rd party. But um, hello??!! YOU LEFT THE DOOR OPEN!!
When you read the word "injected", think "unwitting developer leaving a wide open door for hacker to put stuff on their site". BBC...surely lots of developers, a few development managers, must have some infosec and compliance people. And a hole like that is left open?
Maybe it was a tricky hole or something really brilliant that got around the standard defenses. But I have a hard time thinking that is the case.
In any case, the developers left a hole open.
So my question to you is:
Read the article
Key thing is injected. It almost makes it sound like BBC is a victim, doesn't it? "Hey did you read how the bad guys injected this nasty code into two BBC sites?" Folks, in a sense they ARE a victim, with an unwanted set of code put there by some 3rd party. But um, hello??!! YOU LEFT THE DOOR OPEN!!
When you read the word "injected", think "unwitting developer leaving a wide open door for hacker to put stuff on their site". BBC...surely lots of developers, a few development managers, must have some infosec and compliance people. And a hole like that is left open?
Maybe it was a tricky hole or something really brilliant that got around the standard defenses. But I have a hard time thinking that is the case.
In any case, the developers left a hole open.
So my question to you is:
How many headlines will it take before you change your code?
Don't wait until you ARE the headline...Sunday, February 13, 2011
Developers don't know $#!t about security
"'Developers don't know shit about security'. That may very well have been the most retweeted quote from the 2011 #OWASP Summit." That is a quote from a blog from a big name at the OWASP Summit.
It is an interesting read for sure. I am not sure how to take it. I guess at first I was a little shocked and humbled that InfoSec folks make fun of devs like me. I do realize we know so little about security and they know so much. And I appreciate the blog's point that InfoSec folks should learn more about software development and our unique challenges to get product out the door. But to hear that I am part of a running joke (outside of the ones I know about in my own office)...that stung. And it reminds me how much work we have to do.
I still insist it is all about educating the developers. I didn't know what I didn't know, until I decided to study up on it. 95% of the devs won't study up on security when LINQ, HTML 5.0, and lots of new and sexy technologies are there to learn. We are good at learning the tools of our trade. Security? Isn't that what InfoSec is FOR?
We aren't bad people, or lazy...well for the most part. We put our best foot forward and want to make a good, sellable product. We want the glory. Show me a negative headline with my name in it and suddenly I will pay attention. Show us how the dev down the street, from our own user group, got bitten and now their company is under fire in the press and by customers or shareholders. Whoops! Wake-up call!
It is going to have to come from the developers since we won't listen to InfoSec folks (they don't get us, they just want to box us in, etc). I can't do this alone. Are you willing to step into the gap and point out the elephant in the room?
It is an interesting read for sure. I am not sure how to take it. I guess at first I was a little shocked and humbled that InfoSec folks make fun of devs like me. I do realize we know so little about security and they know so much. And I appreciate the blog's point that InfoSec folks should learn more about software development and our unique challenges to get product out the door. But to hear that I am part of a running joke (outside of the ones I know about in my own office)...that stung. And it reminds me how much work we have to do.
I still insist it is all about educating the developers. I didn't know what I didn't know, until I decided to study up on it. 95% of the devs won't study up on security when LINQ, HTML 5.0, and lots of new and sexy technologies are there to learn. We are good at learning the tools of our trade. Security? Isn't that what InfoSec is FOR?
We aren't bad people, or lazy...well for the most part. We put our best foot forward and want to make a good, sellable product. We want the glory. Show me a negative headline with my name in it and suddenly I will pay attention. Show us how the dev down the street, from our own user group, got bitten and now their company is under fire in the press and by customers or shareholders. Whoops! Wake-up call!
It is going to have to come from the developers since we won't listen to InfoSec folks (they don't get us, they just want to box us in, etc). I can't do this alone. Are you willing to step into the gap and point out the elephant in the room?
Friday, December 10, 2010
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:
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.
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.
Thursday, December 9, 2010
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:
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.
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.
Subscribe to:
Posts (Atom)