Places To Go
News and Reviews....
People To See
Places To Go
Tuesday, July 12, 2011
A friend of mine forwarded me a link to a provocative paper by Microsoft Research that called into question whether the security advice provided to users for their online activities is useful based on a risk-reward calculation. The link and the PDF document can be found here
At first glance I thought that the paper was doing harm by dismissing user security as simply not worth attempting, but that is not the point. The point is that the advice provided to users is often hysterical and out of touch with the real world. This is something I have believed for a long time. So rather than just say,
"yes, that is right, we are screwed", I want to offer up the advice (and mandates) that my own employees and family get when dealing with the security aspects of online security. Here are my Rules of the Road if you will.
The password to my network must NEVER be used for anything else. Violating this rule is worth your job.
If your password is long enough then you never have to change it, except of course if it is known to be compromised. My password to my domain is over 50 characters and it is a pass phrase so since I have never told it to anyone, never written it down, never used it anywhere else, I feel no need to change it regularly (I do change it over time, but not monthly or even quarterly).
You should type in web sites yourself rather than click on links. If your bank sends you an email that something is wrong or they need to talk to you either open a new browser and type in the bank's URL and login that way or call the bank using the number on the back of your credit card or on your last statement. Phishing is the biggest trap out there and always being suspicious of every link in every email is the best defense unless you are a security expert with alot of knowledge of TCP/IP (hint, if you didn't understand any of that you are not that expert).
When in doubt close the browser (and if you like for good measure open up task manager and kill all browser processes).
Have a password plan. For me there are 5 levels of passwords. Level 1 is for sites I just don't care about, but need a password anyways. I use a low security password but a password none the less. It is over 7 characters and has a number in it. Level 2 is for sites that I would not want a stranger browsing as me, but are not a risk to my reputation or my finances. Level 3 are sites like social network sites where I would face some embarrassment if someone hijacked it, but not financial loss. Level 4 sites are things like banking and I have very few of these and while according to my rules I could reuse passwords on this level I choose not to. Level 5 is of course the password for my business network and it stands alone.
If you find the need to write down your passwords then either get a password keeper program like whisper32 (there are many to choose from). These programs are not hacker proof, but the hacker needs to get pretty deep to be able to even start attacking these kinds of programs.
As the X-Files taught us, "trust no one! If someone asks for your password for anything stop talking to them no matter how the topic arrives.
Those are the highlights. I don't try to make users security experts, but I seek to help them exercise some best practices. I am thinking of making this into a presentation for user groups and expanding it out with examples and much more detail.
Sunday, February 20, 2011
While I resisted Twitter for a long time, not too long ago I started following selected individuals on Twitter including Richard Campbell (richcampbell on twitter). I plan to start using Twitter myself hopefully to communicate things of value, but for now I am using it as a comsumer.
This morning Richard tweeted "Four things to write this weekend... is it wrong to do them in the order of how much they pay?". This got me thinking about my own task juggling over the years. When I was in college I learned that there are times that you have more to do than can humanly be done. This was in fact a central part of the pressure West Point put on us while we were cadets there. To cope I came to the conclusion that the juggling metaphor is quite apt. The thing to realize is that not all balls (tasks) are created equal. Some are made of rubber and some are made of glass. Rubber balls bounce and you recover even if you let them drop from time to time. Glass balls shatter if you drop them even once. The key is to identify which kind of ball a task represents and there lies the rub.
We see the same decision points when we undertake software development. I try to tell people over and over that security is a task of glass.
For the record, I think Richard has his priorities correct all things being equal...
Thursday, December 16, 2010
Michele Bustamante and I have started recording the first episodes of our new security focused podcast LockDown. While the website is up, it has place holder content describing Carl Franklin of .Net Rocks fame as our first guest (that was the original plan). However as usual Carl was flying around the globe when we started and we all agreed to save him for later.
If you are interested watch the podcast url or my blog (here) for the first show when it releases.
Monday, July 05, 2010
The Microsoft Identity story has matured quite a bit in the last couple of years and now would be a good time to get up to speed if you have been waiting for the train to get some speed. Vittorio Bertocci has pulled together the training he has been delivering around the world into a training kit including videos of the Redmond versions of the presentations. Check out the June 2010 edition of the Identity Training Kit
Thursday, December 10, 2009
The latest security threat as outlined here
has hit over 100,000 people already and if you read through the details of how organized the attack is you will understand why it has been so successful. The problem is that while we have to protect ourselves from every threat, the bad guys only have to find one vulnerability to lay your plans to waste.
Security is a war, and the hackers are not slowing down their attacks.
Friday, November 13, 2009
I am packing tonight to head to the PDC in Los Angeles and wanted to tell anyone else who will be attending that I am hosting a Birds of a Feather session at lunchtime on Thursday on security hype
The thesis is that we are seeing a steady stream of over hyped security "issues" that tend to remind me more and more of the ads for the evening news that say things like "Your water could be killing your children, details at 11". We plan to discuss how this trend is hurting actual preparedness for the real threats.
Hope to see some of you there.
Tuesday, July 28, 2009
Microsoft has just announced that there are security flaws in the Active Template Library (ATL). While many developers will think that this only applies to C programmers and while to some extent they are correct I think it is important to take a lesson from this issue. Micheal Howard has posted a very informative post to the MSDN Security blog
that I think is well worth the read for all developers (not just C and C++ programmers).
Too many organizations think that they can ignore code once it has been written, but the price of secure code (like freedom) is constant vigilance.
Friday, April 03, 2009
I sent the following email out to our entire company today and afterwards thought it would be interesting to post if for no other reason than to compare notes with others who grapple with these same issues (i.e. everyone). If you have a company of any size at all I would highly recommend sending out semi annual reminders like this one. It helps alot to remind people of the dangers and sets the tone for new employees who have joined since the last reminder. Above all you will note that the message is maturity and responsibility.
The subject of the email was the same as this post (Virus Prevention Advice and Policy) and below is the text:
It is that time again and we are starting to see warnings about worms and viruses passed along by friends and family so I wanted to take this opportunity to remind everyone of how we keep our own network safe and free of these destructive monsters.
Some rules of the road for using company email and company computers:
1. If you did not expect it then don't click on anything in it. This general rule will help you deal correctly with most emails and web pages. If you go to a site expecting to download something be sure that you are on the correct site (many common typos of URLs host malicous copies of the popular site). If your brother sends you a message called, "Kids latest pictures" and it was not something you expected, do not click on links or attachments until you have verified that it was indeed sent by him. Our last major virus here at the company was the result of just such a message being clicked on by an employee who did in fact get pictures from her brother quite often, but this time it was a virus that was sent by her brother's computer instead. It took us 2 days to clean up the mess. A better policy is to only open personal email attachments at home while you are not connected to our network.
2. Be paranoid, but try not to be crazy. If you get an email from yourself that is some form of spam then welcome to the club. We can't stop the spammer in Asia from using your email address to send the world spam and if you use the address long enough it will certainly happen that you and others you know will get spam that looks like you sent it. It will pass, but we can't fix it. See rule #1 as this fact should also make you more cautious of anything you get that you didn't expect even if you converse with the user often.
3. A great many viruses and malware are picked up by browsing the web. Visiting site like Youtube.com and MySpace.com is often a bad idea unless you know exactly what you are doing, why and accept the consequences if the result is 2 days of lost time to the company.
4. There is a reason you can't install things on your computer. We limit what the average user can install on their computer so that if a mistake is made, it is less likely to have a lasting effect on our network. In most cases, if it isn't already installed on your computer you don't need it. There are exceptions, but be sure you have a cogent argument for why you need Software X on your work PC. We also use specific version of MS Office products as a hedge against system outages. We do pay attention to the newest versions and will upgrade when the time is right, but no sooner. If there are business reasons why you need a specific version of something please let me know and we can make a business decision.
5. Keep up the good work. We have an amazing track record here for having staff that do the right thing. Most companies get hit by a virus once a quarter or more and we are typcially only seeing an event every other year. This is in spite of the fact that we do not block sites or regularly check browsing logs to police what people are doing. My only caution on this point is that while we all enjoy this open environment it is dependent on our continued vigilence.
If you have any questions please feel free to contact me or anyone else on the technical staff and we will be happy to help you navigate the mean streets of the Internet.
Tuesday, October 28, 2008
I am here at the PDC in Los Angeles this week and have heard quite a bit of grumblings about UAC. The MS employees on stage and elsewhere are basically saying that UAC is a necessary evil so that clients do not become vulnerable due to unauthorized software install (and other admin level actions). The developer side of this argument is that UAC is a blunt instrument like a security guard in your house that keeps asking you for your passport. You can’t argue that this guard will make your house safer, but he is also going to drive you crazy until you decide to fire him altogether. That is what we are seeing in the field with so many people simply shutting off UAC.
Now that Windows 7 is in sight it might be too late for my suggestion of how we might get the best of both worlds relative to secure software install. My idea is that when you go to install software you should be presented with a Capcha style challenge which ensure a real person is at the helm. Once that Capcha dialog is completed successfully the OS should track that this install is authorized and therefore exempt from future challenges since we know this is not malware (or at least not secretly installed malware).
Since this idea just came up this morning I am guessing I am missing some aspects to this approach that are problematic, but on first look I think this approach could help make things more secure while not destroying user productivity.
If you agree then bring this suggestion up to the people you know at MS. That is what I am going to try to do later today.
Friday, March 21, 2008
I have often thought about the mindset required to be good at the security game. I hang out with Duane Laflotte alot and he has the penetration tester mindset which lends itself nicely to security even when you aren't trolling on the dark side.
But it was an article that got picked up on Slashdot today about Bruce Schneier's
thoughts on this subject that revived the thread for me.
I have what I think is an interesting twist on this perspective in that I believe that the only way to teach what Bruce is holding out as unteachable is what I believe taught me to think this way. When I grew up I didn't think the way Bruce Schneier thinks. But I do now. The reason I believe is the military. When the Army trains infantry leaders it teaches them how to defend while looking always for ways to attack. The mild mannered programmer is taught to build, but if part of that training put in their mind that to be successful they had to tear down the abilities and infrastructure of the hackers then we might get a different result.
There is nothing to make you think like a hacker than to stand on a hill and realize that you are defending it at dawn and if you fail you and all your soldiers die. It also makes you want to get that unfair advantage and lay traps for the enemy. During a major training exercise in Germany I put soldiers in foxholes with signal mirrors and had them flash the enemy armor to draw fire while our vehicles flanked and destroyed them.
So I think if you want to be a hacker and you don't think like one I think the Army recruiter would be happy to help get you trained...
Tuesday, February 27, 2007
Most companies pay lip service to security, but the emphasis is just not there. There is bluster and maybe even a few conversions soon after an embarrassing security breach, but all too often a scapegoat is found, fired and then it is back to business as usual.
The missing element is real financial cost. Looks like Massachusetts and hopefully the feds will change that with new laws that make companies that get hacked pay for the cleanup.
I really like this kind of accountability. While I don't think it will be a panacea solving all our problems it will put those to blame for these problems clearly on the hook for paying to clean them up.
Hopefully other states and Congress follow the lead of Massachusetts.
Friday, February 16, 2007
ZDNet recently had an article about new attacks
and I work on our book (I know it is about 2 years overdue), we are struck by the fact that there really aren't many new kinds of attacks, just more ways to exploit the same old stupid mistakes people seem intent on ignoring forever.
If you bought a combination based high security lock system for a new car would you change the default code? What if the code was 0000? Would that be enough for you to realize that anyone who ever took a test drive or just made an effort to think about it could guess your code? Read the article and just think about how ridiculous this would be in any other arena other than computers. If we could just get people thinking about this stuff I think we would go a long way to reducing the security problems we see. The Spam storm that is clogging the Internet lately and other incidents might be much less common if this one little change could occur...
Wednesday, January 03, 2007
Forbes.com has a story about the use of typing patterns
to identify whether a user is the actual user or a hacker.
I like the idea, though I fear it won't catch on. Defense in depth, adding an edge is important, but the key element from this article comes at the very end where they say that if they suspect the user is not legit they will ask additional questions. This is the key to preventing (for the most part) denials of service to valid customers while still having a chance to catch the bad guys.
Wednesday, November 29, 2006
My good friend, Eileen Rumwell, has started blogging
. Her blog is something I plan to keep watching especially since in the short time it has been up she has already thrown out some great insights. The really cool thing is that having come from a marketing background, Eileen has been thrust among developers for quite a few years now. Working at Microsoft she has great insight and maybe more importantly she also has insight into how we developers outside MS work and think about our role.Eileen's latest post
starts off talking about her dogs and quickly points out that developers seem to think that security is not their problem. I have seen this attitude quite a bit, but typically I get to beat it out of those who exhibit it to me since I am often cleaning up after a problem or onsite to beat it out of them.
Ignorance and apathy are both alive and well in the development community. It isn't the people who are motivated and willing to drag themselves to the user group meetings that are the problem it is those that are likely too lazy to even read a blog about their chosen profession let alone one about something tangential to it. If we hold our breath long enough the world will evolve and security will be baked in to everything that matters, but that is still a long way off if a majority of those building the future think that this whole security thing is a fad. Lets vote them off the island.
Sunday, November 26, 2006
Time magazine's cover story is about how people are scared of very, very unlikely things such as bird flu which hasn't killed anyone in the US while the regular flu kills tens of thousands each year.
Security is the same way. I often see organizations worrying about "Carlos the mad hacker" when their own IT staff might be the real threat.
Thursday, November 23, 2006
Microsoft has just released their new Anti-XSS library which helps developers do the right thing more often without as much effort as before.
If you are interested in this (and trust me, you are) your first stop is to go to the tutorial and see how it is done. As you will see it isn't stupid simple, but an improvement.
Once you get confortable then go to the official page and download the library and make it part of all your web projects.
Monday, November 06, 2006
Chad Hower is a smart guy and I came across his post on protecting the software you write from pirates right at a time that we were revisting the question ourselves.
On the whole I agree with Chad, while he comes off as against anti-piracy in the beginning of the post, in the end you realize that he is just advocating for a measured response. I couldn't agree more.
This is very much the whole, "In order to save the village we had to destroy it lesson" where you get very diminishing returns if you go too far off the deep end in trying to make your code pirate proof.
Monday, October 23, 2006
I have commented before on this issue and a recent blog post forwarded to me
has dredged up the topic again.
If you want to get rid of a drive after retiring a server or getting indicted then most of the things you can think to do to that drive will not remove the data. You can rewrite the drive over and over, you can shatter the platters with a hammer and as we see in the link above you can even roast the drive and it is still possible to get at some of the data if not all of it.
For my money the only way to go is acid bath. If you don't remove the surfaces of the platters then someone will figure out how to get the data.
Wednesday, October 18, 2006
Sometimes the Fear, Uncertainty and Doubt (FUD) argument is very well disguised. In an article the Chief Scientist at McAfee
is decrying some of the new features that MS is putting into Vista to try and stop virus infection and the spread of spyware. This is terribly self serving as in my opinion his argument is that you can't sell people better doors for their house because then they not only won't need my security system, but the doors will keep the police out when a criminal arrives.
Everyone is entitled to their opinion and the comments under the article show that alot of people who read this opinion, share mine.
Thursday, October 12, 2006
As Vista nears launch there are some things you will want to know. Will it support your hardware? Where are the secret buttons that make it usable?
Today's post helps answer that second one.
By all reports UAC (User Account Control) can drive even the most security minded user insane with death of a thousand dialogs.
While I don't recommend just shutting off any feature that is designed to increase security in the OS (as UAC is), still we have to get work done and it might help you navigate so that you can reenable it once your system is as you like it.
Having said that, Steven Smith of ASPAlliance.com pointed me at this article that shows several ways to shut UAC off.
Wednesday, October 11, 2006
Steve Riley had a good long post on his blog about Mandatory Integrity Control as it is implemented in Vista that drew even longer comments.
Great concept, as you will see from several of the comments, this isn't the first implementation, but I expect it will be the first to get nearly universal distribution ;)
The big concern is whether the bugs will be worked out for release. I am betting yes, though I expect a Service Pack will come someday to bring the real value of this home.
Tuesday, October 10, 2006
My prolific friend Phil forwarded me a story about Chinese hackers trying to do in the US Commerce Department.
There are a couple of interesting points in this story:
1. Why would you need to take Internet access away from users? Aren't they behind firewalls? Were the hackers luring them to specific sites to hack them?
2. With over 1,100 laptops missing, I just buy that no data was compromised. Even if it was an ex-employee the data is compromised. And if the theft occurred in 2001 then I find it even harder to believe.
I hope the CIO at the Commerce Department isn't gullable enough to believe this obvious spin.
Tuesday, October 03, 2006
The topic of the AT command and the command prompt came up on an internal list I am on with Microsoft the jist of which was, "How do I securely turn this junk off".
The answer is that to some degree the command prompt and especially when coupled with the Task Scheduler is a security hole that is closable, but not trivially. You can patch it using things like this http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/93465.mspx?mfr=true
and you if you really want to wipe out the user's option you should reset the task scheduler service to use a low / no priv account and disable it (I am paranoid, but I have my reasons). The problem is that the perspective of most that come up against this is that you shouldn't have to do this, but the reality is that you do.
For a scary look at why simply taking the RUN command off the Start menu is not enough try the following:
Open up "Help and Support" from the Start menu and seach for "command".
Select the entry that describes how to "Test a TCP/IP configuration using the ping command"
You will see that there is a link that will open up a command prompt (it doesn't run as System, but it runs).
That is the XP version.
The Windows 2003 Server one takes more searching, but it is there.
The issue is not that the functionality exists, we all want functionality. The problem is when it is hard (or impossible) to shut something off effectively it is maddening and often leaves people dismayed.
Time for an analogy:
I have doors on my house that I leave unlocked all the time. The dogs and other things in the house keep it secure (if you know me then you know what I mean), but if I wanted to secure those doors and found that I could lock them, but the manufacturer set them up so that the hinges were on the outside and manipulatable by an intruder then I would be unhappy. Most security outrage and dismay comes from features that just didn't take security into consideration for the times when I don't want the user to do anything except what the user is told they can do.
This will always be an arms race. If one of our professional security gurus such as Duane Laflotte wants to get in and has physical access to a workstation or server then he can get in, but there is a point where I will say, yes I accept that there are some things I can't defend against. If you use a tank to blow in my front door, I won't moan to the manufacturer about them not being tank proof, that is what the mines are for ;)
Is Vista the solution to all security problems? I doubt it. I expect that there will be improvement based on features I already know are in the most recent builds, but I won't judge the security of Vista until after it ships (and won't pay all that much attention to it until then either) since the devil is in the details and the truth is in the final bits. Submarines either leak or they don't. The OS will be judged in much the same way in regards to security.
Ultimately information is power. Nowhere is that more true than in the realm of security. I suggest that you learn all you can and I will do what I can to help.
Monday, October 02, 2006
If you want to keep track of how prevelent phishing attacks are from month to month (and I do) then you should check AntiPhishing.org. The site is pretty meager in most regards, but the front page has a bar chart that is pretty staggering when you realize that they are only measuring people who have actually figured out that there is a phishing attack in progress (a fraction of the population I am sure) and further restricted by the fact that those astute people had to know about and be willing to take the time to report it to AntiPhishing.org.
I find these statistics interesting to have as spin seems to creep into everything nowadays. I like to lay my hands on hard numbers and make up my own mind.
Friday, September 22, 2006
There are many varying opinions on almost everything, but Compliance is one of those topics like economics, everyone has a different opinion it seems.
I was reading an article by one of the Systems Engineers at Network Appliance entitled, "Six Tips for Archive and
Compliance Planning" and while I agree with most of the points Mike Riley makes, I had to think a bit about his words on Encryption.
He isn't saying not to use encryption, on the contrary, he is saying that encryption is a must, but the advice is sound. Be careful what you do and the ramifications. With compliance systems, often search and rapid retrieval are key and these are some of the most plausible arguements against specific applications of encryption.
As always, look before you leap. I guarentee that if you think about where you should be using encryption you are already ahead of most.
Wednesday, September 20, 2006
It seems that even though we all know we need to patch our system, we are now having to do it faster and faster to avoid the vulnerable time between patch availability and exploit. In an article on ZDNet
there are details of how the latest exploit is being used, but soon you should see a post by Duane Laflotte on his security blog
about how it isn't just being used on sites you might expect. Even the super computer savvy gamers are getting hit and I have to think that in many cases we just know about this because they realize. How many never figure out that they are maintaining a drone in the hacker army of some malcontent 15 year old with a grudge...
Tuesday, August 29, 2006
I am sure it is reported elsewhere, but I found an article on a proof of concept virus that targets AMD processors
on a magazine site in Australia. The article dismisses the threat of such an item and pretty much holds it up as just a curiosity in the fight against hackers, but I see it differently.
In order to win, eventually security has to be hardware based. The whole Palladium (now known by the horrible NGSCB acrynym) effort is just the most public manifestation of this realization and even it has gone dark. Hacking the hardware is hard, hacking the software is easy. Software provides the security of a screen door while hardware security done well can be like a steel cage. Watch as this develops. Like gas prices driving the frantic (and belated) search for alternative fuels, it will be a mind blowing security threat that finally forces us to invest in security via hardware in real terms.
If the barrier to enter the hardware market in a significant way weren't so large, I expect this problem might already be solved...
Friday, July 14, 2006
I was just thinking about one of the bugs listed in the latest hotfix from MS and realized that while aspx and config files are not at risk since they are mapped to aspnet, the express database if stored in App_Data probably is.
We don't typically use SQL Express, but my bet is that this is the greatest risk factor for this bug. Thoughts?
Thursday, July 13, 2006
When I see an article like this one in eweek, I always wonder about how the people doing this cool thing will make enough money (or any money) so they can continue to do these cool things.
Basically they are using the Google Search APIs to ferret out sites on the Internet that are hosting malware. I think this is great, but the article didn't say how this cool thing would be actually used to benefit the world. If they notified site owners that they had malware and pointed out exactly what was where then there is no profit in this (Do I sound like a Ferengi here?) which means it isn't likely to be sustainable. But what if they notified sites the first time (civil minded) and offered to keep them updated in the future for a nominal annual fee.
I find that many great ideas languish and die because people want to hold onto the open source kind of dream and for some reason either don't see how to help the community in a self sustaining way or are just worried about being accused of just being out to make a buck.
Thursday, May 25, 2006
If you are into threat modeling (and you should be) then you should check out the latest version of the product formerly code named "Torpedo". I think this is the first product to make real strides (bad pun intended) toward making threat modeling more approachable for the average developer.
Get it at:
Monday, May 08, 2006
At Code Camp 5 in Waltham this past Sunday I was delivering my session entitled "All you need to know about Membership", when I learned that I didn't know everything I need to know about membership.
Someone asked if the scripts were available that aspnet_regsql.exe uses to create the membership table. My answer was that I hadn't seen them so I assumed they were baked into the exe. WRONG! Our good buddy and fellow Code Camp presenter, Dan Krhla, pointed out that in the same directory that you find the aspnet_regsql.exe (namely C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727) you also find the scripts that the tool users including InstallMembership.sql. There are a bunch of them and you have to install them in order (installcommon.sql first, etc.). They offer some good insights and I have already spent a bit of time on them myself.
Thanks again Dan and I am happy that the question came up so I could learn something too. This is why I really love the Code Camp.
Wednesday, May 03, 2006
MS has committed, at some level, to support VB6 on Vista. In an article from February there are some details, but we now know that if you have a VB6 application that you cannot live without, you will probably be OK for years to come.
This is both good news and bad news. While I feel the pain of people who depend on these legacy tools for their products to work, I can't help wincing when I see this because old tools support old techniques and technologies that are often just not up to the task of building secure applications. Everything from cryptography to SQL Injection have evolved as have the tools to combat them.
If you are using / depending on VB6 then congratulations, but my advice is to get off of it (from a seasoned VB developer) unless you can really and truly convince yourself that it poses no weaknesses in security based on your use of it. Eventually you will have to jump.
Thursday, April 27, 2006
A friend of ours, Phil, sent Duane and I a link to an article about web attacks (Phil does this alot). He commented that he hadn't heard of CRLF Injection before and while I had heard of it, I realized that I wasn't comfortable explaining it on the spot with examples so I read the link.
While I think the writeup is good and felt refreshed of information on the topic (as esoteric as it is given how often we still find SQL Injection), I was struck by one badly worded comment in the text. Namely the section that says, "The best way to defend against CRLF attacks it to filter extensively any input that a user can give. One should "remove everything but the known good data" and filter meta characters from the user input. This will ensure that only what should be entered in the field will be submitted to the server". The premise is well intended, but did you see the flaw? Why would you remove anything from a submission that has anything bad in it? OK, maybe there are innocent times when a user will insert something that doesn't belong. However if you are doing the filter thing and you find something bad, overtly bad then you shouldn't remove it, you should end the user's session and redirect them to an error page (or some other circle of hell).
If a criminal came to your house and tried to open a window only to find it locked would you then allow them to keep trying? If you can determine that the input was actually harmful (the opposite of good data) then you should think hard about maybe dumping the user and not going any further in their processing.
If you make your applications work more like the way the real world works then they are more likely to survive in the real world.
Friday, April 14, 2006
Scott Guthrie pointed me at a link to the source code for the ASP.Net 2.0 providers including the Membership and Role Management providers. While I think the Profiles, Web Parts and Site Navigation providers are important and cool, I expect to do much more with the Membership provider. Expect to see some customizations in presentations I give in the future.
I think this is a great step and am not surprised to see Scott doing something this cool.
Check it out!
Wednesday, April 12, 2006
I was recently asked by a very technical and very sharp friend of mine about the symantics of permissions on copy.
I figured if he needed some guidance on how this works then there must be a ton of other developers who could use a refresher so here goes:
There are alot of reasons that a developer or QA engineer must use copy or move to get their applications running for test or even for production. The problem is that the same old processes that worked so many times before can often mask a misconception or two that arise as "bugs" when the moons do not align to make the old process function as expected. Case in point. You want to deploy a web application which has notoriously particular permissions requirements. If copy has always worked in the past, but on the new server you are getting strange permissions then you might be forgetting some of the rules.
The first thing to take into account is whether this is this a move within the same volume (nothing fancy) or a move across volumes (maybe obscured by DFS) or even just a plain old copy (often the case).
A move within volumes would mean you should have the permissions preserved. A move across volumes is actually a copy and a delete combined and means you are just getting the permissions of the target folder which is by design and this is also the behavior of a copy unless you use something like scopy which preserves permissions.
If a copy in the past has preserved permissions and you didn't use scopy (very handy by the way) then either there is a setting in Windows that I am unaware of (please enlighten me) or you got lucky in the past and the target folder permissions were what you expected.
Usually file permissions and especially the semantics of permissions on copy vs. move are the domain of network types. In many cases it helps alot to be a mongrel from both worlds.
Monday, March 27, 2006
Wednesday, March 22, 2006
In dealing with our teams of developers and engineers I find myself preaching some basic rules that make life easier for me when I try to deal with the legion of emails I get every day. I thought to document them and in doing so realized that they have a decidedly security slant to them (big surprise).
Here are some rules of etiquette that will allow you to survive my spam filter (outlook junk mail) and not get deleted for cause:
- Always put a subject on the message (the more specific the better). I am noticing a ton of no subject emails in my junk mail folder and I don't scan the addresses before I delete them. Not putting in a subject is a technique used by spammers to make you view the message. For me and a growing number of people it backfires. Call it a pet peeve, but if you can't be bothered to put a subject on a message then I can't be bothered to read it.
- Never send an attachment unless I expect it (you told me in a previous message that you are sending it) or you explain what and why you are sending it in a way that lets me know that you had to have written it. Remember that anyone can send a message as you if they really want to do it.
- If you send me a link then tell me what is at the other end. There are many sites that lure you in and do something amusing. Why would you assume that they aren't being used to infect or subvert your computer. There are many "drive-by" exploits that only need the page to be viewed from a vulnerable machine to do their work.
- If I know a password or other secret then you can refer to the password or secret, but avoid sending it in an email. It just isn't a secure medium.
I could go on and on about all caps being like yelling, but that isn't my intention. I had figured that everyone already knew about these and yet I still get these things sent to me times per day and often by very technical people.
Tuesday, February 28, 2006
Monday, February 27, 2006
If you are at all into security or even if you just think technology is cool then you have to watch the latest episode of the The Code Room
. In this latest episode you will see our own Duane Laflotte, our resident top security expert as part of the team of evil doers that hack a casino in vegas.
I think it is really well done and makes some good fundamental points about security in a very entertaining way.
Friday, February 24, 2006
When I was in Cairo for the MDC a few weeks ago, I gave several talks that touched on the new membership controls in ASP.Net 2.0. One question that came up repeatedly was how far can you stretch the provider before you have to write a custom membership provider. The answer turns out to be not very far. The provided membership providers are very good and very extensive, but they are also fairly rigid in their implementations.
I think I have the 3 criteria that will force you to realize that you need to bite the bullet and write your own membership provider:
- If you need to access your own schema that is different (in any way) from the schema provided. Running Aspnet_regsql.exe creates a database and if you need to edit that schema then you cannot live without a custom provider except if you are adding tables for your own use, but bear in mind that the provider will just ignore your additions.
- If you need to access data in someplace that is not supported. Even if you want the same schema as the default providers support, you cannot use a proprietary database for that data and expect the providers to just work. The XML provider is the most common example (though not very real world), but you could think of many scenarios including SQL 7.0 where a custom provider would be in order
- If you need / want to insert some abstraction between the provider and the data. Stefan Schackow of Microsoft had a great session at PDC 2005 in which he demonstrated creating a provider that allowed for the situation where your web servers were not in direct contact with the database server. To solve that problem he wrote a provider that took a web service endpoint as its connection string.
So as you can see you are quite likely to find yourself having to write your own provider. The good news is that it really isn't that hard to do once you have done it once or twice ;)
Monday, February 20, 2006
Dominick Baier of DevelopMentor, wrote on Saturday about a pretty dramatic change in the way ClickOnce security
is configured by default in the RTM version of .Net 2.0.
This is a must read if you plan to use ClickOnce and haven't already revamped the default security settings. If you don't like the ramifications that not being able to disable ClickOnce brings then rather than avoiding the .Net 2.0 offering you might consider the lesser step of just removing the .application mapping from your systems.
I am hopeful that Microsoft will come up with a fix in a service pack to .Net 2.0 as they did in the original .Net 1.1 that will address this default.
Wednesday, February 15, 2006
A recent court case was brought to my attention in which a user whose personal and financial information was stolen tried to sue the company for not using encryption on the data. The article covering it is explains how the data was stolen and the ruling of the courts.
The question raised is whether the suit should have been supported? While I agree with the ruling, I think that certain industries need to actually gradually design best practices like the use of encryption into their required security precautions. This may be pandora's box, but if it is done over time then it might actually be done right (wishful thinking?).
Security is still black art to most people. We need to define "reasonable measures" in ways that make sense to the masses.
Tuesday, February 07, 2006
I was asked by my publisher at Sys-Con to send him my reaction to the comments on Slashdot.org about the test this month that the U.S. Dept. of Homeland Security is doing that are being called CyberStorm. Rather than repost I figured I should provide a link to my comments, but I can sum it up by saying, I hate cynics
Wednesday, February 01, 2006
Thursday, January 12, 2006
As the title of this site states, it is a real battle to keep up with the technology and an even bigger challenge to have a life along with that effort. On a fairly regular basis now I realize this when a standard feature of a widely available tool or technology is virtually unknown and therefore unused. I am pretty sure that queries in Active Directory falls into this catagory.
In Active Directory Users and Computers you can create custom queries through the MMC that can help you track down security problems that are very work intensive to do manually. In the Common Quesries dialog you can even check a box to search for Non expiring passwords and disabled accounts. Disabled accounts aren't very interesting since the UI gives you that list in a browsable AD, but accounts set to bypass the password expiration rules are a perfect way for an outgoing administrator to create and preserve a backdoor.
Check it out, who knows what else you might find in there!
Wednesday, January 04, 2006
Mark Russinovich has posted another excellent article on Spyware, this time pointing out the anti-spyware program as spyware strategem.
If you hoped that Spyware would just go out of fashion sometime this year, you are deluded. The advent of better Rootkits, bogus anti-spyware programs (like the ones Mark points to) and the underlying profit makes this the cocaine of the Internet. The problem is that all the victims are truly innocent in this case.
I want to thank my buddy Dan Krhla (DanK) for pointing it out for me. He is a very good source of what is good on the Internet.
Tuesday, December 27, 2005
I was asked by Sys-Con to make my predictions for 2006
and while I am loath to do this kind of thing, I did venture some. We will see whether they turn out correct or not in about 12 months.
Wednesday, December 07, 2005
I am amazed that web developers often don't know IIS configuration as well as they should given it is the platform all their code must run against. The most pressing misconception concerns Basic Authentication. When you configure a web site to support Basic Authentication (a modestly practice) it encodes the user credentials. Get this straight though, encoding doesn't mean encrypting. It just puts it into a format for transmission. That format is public and completely reversable which makes it as secure as clear text.
While I don't want anyone to take this as a rant against Basic Authentication, it is a wake up call because the credentials are sent on each and every request of the site using this authentication mechanism. This means that if you use Basic Authentication you need to use SSL on every page request. This is the detail I see missed most often. I have seen many sites that put SSL on the login page, but the credentials still get sent clear text for the entire server to client communication.
Bottom line is that if you choose the mass support of Basic Authentication, you have to accept the overhead of using SSL on every single request to the site.
Monday, December 05, 2005
I was browsing through the list of wireless vulnerabilities on the Wireless Vulnerabilities & Exploits site (our buddy Phil C pointed it out to me) and I was reminded why I always turn Bluetooth off on my devices or avoid them altogether.
Maybe it is just that "B" is so early on, but there do seem to be way too many exploits for this technology. Granted someone has to often use a bluetooth gun or some sort, but that isn't as far fetched and just adds to the randomness of the attack.
An improved vision of Bluetooth or it's successor:
I want to see a version of Bluetooth or some replacement technology that does the same as far as functionality goes, but that has a metal contact on both device and accessory which must be placed together with physical contact in order to exchange public keys that they will then use along with unshared private keys inside the devices to make the communication not only authorized, but encryptable. Why is this so hard? This idea has been with me for well over a year and I just expected someone would implement it as Bluetooth 2 or something, but if it does in fact exist, I haven't heard about it yet.
Sunday, December 04, 2005
A friend of mine who is doing business with us posed an interesting question about the digital nature of our contracts. He said that with paper contracts you have the original that can be examined for changes and modifications. You can’t white out a term or condition or add a few zeros to you compensation without someone being able to prove that you altered your copy. Plus the both parties tend to keep a physical copy for comparison in case of one party contesting the contract. In many cases we do business with contractors via a contract that is emailed as a PDF or sometimes as a Word document. The contractor prints the contract and signs it. Often we get only the signature page faxed back to us.
My security minded friend points out that, “it is easy to add or remove any word using any number of tools, in other words I may add an extra zero for my salary or change any thing, so how this issue is solved using digital contracts?”
My answer is that we ask the contractor to fax back the contract with a signature. Our records in email show us sending them a specific document. Without email documentation confirming changes or a new document sent to them there is support that the signature is based on the document we sent. While it is possible to change systems, it usually leaves detectable footprints and it is unlikely that we would do contracts with 10 or 20 people in the same geography or job type and dramatically change the contract for one individual. In this case if the company typically uses similar contracts it can be a benefit in supporting their side of the claim. Ultimately the courts typically do the right thing in this regard and can decide when something has been altered, even when done expertly.
Even so, there is nothing like a confirming email after the contract is sent and another after the signature is received that covers the essence of the deal to add proof of your intentions in the face of an altered contract.
If you want the real answer then you likely have to ask your own legal counsel as I am not actually a lawyer or trained in the law beyond the basics of military law. The point of this is that here is another vector for manipulation and attack. Have you planned for how you would respond?
Monday, November 21, 2005
I try to read the blog of Dave Hitz, one of the founders of Network Appliance, and while I don't link all the time I found one of his entries pretty on topic.
Like my title above, Dave stole the most provocative words from his post to stir interest. His post is titled, "Beware of Cyanide Gas".
Another fine example of security is such an arms race. I recall talking to clients just a couple of years ago and the standard was that server disks should be wiped and then destroyed. That is still the standard, but the definition of destroyed keeps moving on us. Dave points out the ridiculously small slivers of intact disk platter needed to read data and the reaction of one our our more security conscious customers was, "I guess we will have to add an acid bath after we sledge them...".
A big part of this battle is just staying in formed on what can be done and then figuring out whether you care or not. If you have passwords and huge databases with Social Security Numbers or Credit Card numbers then letting someone read even one sliver of the platter may be disaster (though small by today's standards as massive security blunders go).
Always think about the level of response based on the threat. If a serial killer escapes in your neighborhood then you are justified to double the locks on the doors and get a bigger dog, but if they escaped 3,000 miles away from you with no history or indication that they would come looking for you then you are overreacting. If you apply these same standards to your electronic response then you will probably come out alright.
Lastly, as always watch out for the cyanide gas!
Thursday, November 10, 2005
I had a conversation with a friend of mine recently about the physical protection of his home. I have a bit of a reputation as a gun enthusiast that is somewhat earned. What surprised my friend and got him to urge me to post this entry is that my advice was a surprise to him and something he admits he had never heard before from anyone.
The issue wasn't computer or even company security, but security at home. How do I protect my family in a world where convicts escape, kids kill and home invasion is a common occurence? I do have weapons including an AK47, but they are not ready at a moments notice. I have kids so I have bolts out and disassembled, ammo stored away from the weapons and trigger locks (in the case of the AK there is a cable locked through the barrel). I can't just run and grab one of these weapons for the defense of my home and that works since that isn't my plan. We have 3 dogs who average about 70 pounds each and should they alert me to a problem I am most likely to grab my paintball gun or a wooden sword to join the fray. If I confront an intruder in my house with a paintball gun then there are several advantages. I won't be having rounds going through walls and hurting my family or pets, I won't be causing a fire or water damage with paintballs, but if I put 20 rounds into someone at close range they will be down. Anyone who has played paintball knows what I mean, especially if they have been hit from 10 feet or less (not recommended). I live in NH which means that I am unlikely to be prosecuted should I kill someone invading my home, but why make killing the person a goal? I view it as impossible for a court to convict someone if they choose an obviously non-lethal weapon especially when given more deadly alternatives.
I know this seems to be off the topic of security as it relates to technology, but if you have been reading my posts you know that I don't see a distinction in most cases. Security is security. I would welcome your comments on how this concept (well recieved by all I have discussed it with) might apply to technical security. I will reserve my analogies for now.
Thursday, November 03, 2005
Mark Russinovich is a brilliant guy and likely not so popular with the people at Sony these days. Mark was testing out some root kit detection and removal software and discovered that in their exuberance to implement Digital Rights Management Sony has created a very ham handed solution that behaves more like a rootkit than some of the very worst actual rootkits out on the Internet.
Read Mark's Blog which details his discovery or go to theregister.co.uk article that summarizes it. Good reading about bad code!
Monday, October 31, 2005
A friend of mine has a system that will require them to generage a large number of username and passwords for their users and they want to use usernames that make sense to the users. That is a common request, but he is concerned that a saavy user could deduce the username of others based on theirs. This is a real possibility (or likelihood) if you use any of the standard methods such as employee number (just guess sequential numbers) or combinations of first and last name.
My response is as follows:
It is as always a tradeoff...
If you use a determinable username then the password must be that much more secure. Ultimately we accept that user names are often guessable (in most systems), but just because that is a normally accepted risk it does not follow that it is OK. Password guessing is a numbers game. If we go to the simplest case of a single character password using a standard character set (alpha upper case + alpha lower case + digits = 26 + 26 + 10 = 62 possible characters) then there are only 62 guesses needed to get in once the username is known. As we add more characters to the minimum password length then we approach numbers where brute force attacks will take a long time provided the password is not in a dictionary (my dictionary for such attacks has over 5 million words and well worn passwords). At 6 characters you are at 56,800,235,584 (over 56 billion) possible combinations assuming the simple character set I mention above. On average an attacker trying every single possible combination will stumble on the correct one before they finish every combination. Keeping that fact out of the discussion we have to decide if we think a user can hit the site 56 billion times in a reasonable span of time to guess the password. Drive minimum password length to 8 characters and we are at a healthy 218,340,105,584,896 (over 218 trillion) which is where I like to be.
This is very secure given one critical assumption. It is assumed that the overhead of making a web request to test a guess adds enough overhead that you can't hope to achieve millions of guesses per second or even per minute. If this assumption falls then my conclusion below for a web based system is out the window. Windows hashes of 8 characters fall very quickly even with larger character sets because I can crack them locally leveraging the full power of my processor and not bound by network latency (which is huge in comparison to local throughput).
Bottom line is that if you are comfortable with 8 character passwords that are complex enough (not findable in any competent hacking dictionary) then you can publish the user names on your home page and it won't matter (but I wouldn't because I am paranoid).
One final analogy to wrap up: If you had a combination lock with the typical 4 numbers on tumblers (locker lock or suitcase lock). There are 10,000 combinations from 0000 to 9999. If someone could deftly try one per second then in under 3 hours it would be open without exception. But if they could only try once per hour (due to surveillance or some other factor then it would take well over a year. Complexity is comprised of number of characters times character set available. Vulnerability is measured in potential passwords divided by the speed at which they can be tried. I prefer adding techniques that detect and deter brute force attacks, but that is a topic for another day.
Friday, October 14, 2005
My nephew, John Hynds, also happens to be a security consultant (big surprise) and he pointed me at a recent what we think it a perfect example of a Cross Site Scripting (XSS) exploit as carried out against MySpace.com.
We find that most people have trouble understanding Cross Site Scripting as an exploit as opposed to more transparent attacks like brute force or even SQL Injection.
One key take away from this is that while you are welcome to try to detect when a user inputs malicious data, but that is a war of escalation. Instead you should concentrate on only allowing valid data, it is much easier to screen and less likely to fail as MySpace.com did in this example.
Friday, October 07, 2005
The vulnerability scanner called Nessus will no longer be available under a GPL license starting with the next version (version 3.0).
The announcement pointed to the fact that the community has done very little to help the product evolve, but many competitors have exploited the loophole of providing hardware appliances to cut the makers of Nessus.
Friday, September 30, 2005
Tuesday, September 27, 2005
The three major credit companies are banding together to put all our eggs in one basket. On many levels this kind of uniformity makes sense as it likely means more resources are being put on the problem, the consumers of the credit information are less likely to make mistakes associated with trying to juggle three different implementations and there will be more focused scrutiny on this unified security, but it also means that if you crack one, you get them all. A friend of mine who is very active in the developer and security community, Phil, forwarded me the article from Eweek
that outlined the effort in very vague terms. Overall I think it is a good step, but as with all things secure, there are very few solid patches of ground.
We do the best we can, but it is very important for those that hold our information for us (whether we like it or not) to do the best they can.
Tuesday, September 20, 2005
Many security experts who I hold in the highest esteem are ticking me off!
I hear it all over that, "you should never use obscurity as security" and while I agree if you put the word "only" in front of obscurity, but otherwise you are often teaching the wrong lesson.
When I was in the Infantry, we had these things called tanks. They didn't rely on obscurity for their defense. They had several feet of armor in the front and often a 120 mm smooth bore cannon backed up by a couple of machine guns, but we did camoflage them. We did try to prevent them from being obvious. The truth is that obscurity is a layer in the overall defense. It is not a fool proof layer and on the Internet, in some respects it is not even a very good one, but I want all the layers I can get. If obscurity isn't important at all then publish your schema and your overall architecture. I am taking it to extremes, but we need all the help we can get in all things security.
I know that in a conversation I can get agreement on my point from those who are trying valiantly to just teach a valuable lesson, but I think the wording has to be more exact.
Maybe my war analogies are misplaced when it comes to Internet security and defeating hackers, but no one has convinced me of that yet. It feels like war to me!
Security is a war, don't fight fair!
Monday, September 19, 2005
While I was at PDC I attended a slew of NDA briefings from Microsoft. During one of them a flash went off and some people got understandably upset that someone might post a picture of a product being shown under strict privacy. It turned out that nothing untoward occurred and no picture was posted where it shouldn't be, but it is the perfect situation for products that actually prevent bad behavior in this regard. A friend of mine, Scott Stanfield
, pointed me at this url
which discusses technologies that are emerging that will handle this exact situation.
Friday, September 16, 2005
As I got caught up on the activities here at the PDC in Los Angeles, I fell off the wagon of posting about what has gone on. Overall it was a good event, but there weren't a ton of surprises. As I write this I am listening to Michael Howard explain the updated threat modeling thinking that sounds quite good. The push in threat modeling is to make it accessible to developers who aren't security gurus. This is a good goal because I can count on one hand the number of clients that I have visited that actually do real threat modeling. As the tools do more and more for us, this is the high value, non automatable activities that we need to see more in the enterprise.
This shows that MS is making a push on all fronts. There isn't any complacency that I can find, though occasionally there is some confusion.
I have heard over and over again from people that you just can't keep your hands in everything anymore. The number of products coming out based on the announcements here this week alone bring this point home. Lets hope that it doesn't go so far that we ever get to the point where someone narrows their focus so much that they decide to become experts specializing in the File Menu of Word (and all 3487 entries and shortcuts in that menu)...
Tuesday, September 13, 2005
I am writing this from Bill Gates' keynote at PDC in Los Angeles. User experience is definitely the message of the day. Windows Vista is a clear indication of the MS belief that if you build a better interface then they will come (or stay as the case may be).
Atlas, which will allow MS technology developers to build XMLHttp based, google map like, experiences is a prime example that this is the battlefield of this round. There was a bit of a history lesson that was likely very unneeded given the crowd, but then WinFX (highlighting Avalon), Windows Vista and the supporting technologies were covered.
Windows Vista is supposed to, "Bring clarity to your world". The Vista demo was cool, it is hard to call it anything else. If you like the UI in Windows XP then you might have a hard time being lured to Vista, but if you have ever envied the Mac interface then you will have to dig a bit to find enough justification to jump. Control and security are the other motivator. Phishing attacks have been increasing dramatically and IE 7 goes a long way to allowing you to be much more confident that you aren't being victimized. The dynamic protection service will let you opt in to view a known phishing site so that you are never really prevented from hanging yourself. I think this is a good example of MS keeping pace with the hackers, the problem for many people is that they may not want to move, but security will force the upgrade ultimately.
Office 12 was announced and will be released at the same time as Windows Vista. The biggest changes are to the user interface (basically reinvented) and the intrinsic XML file format.
Wednesday, September 07, 2005
I had a very interesting discussion that manifested itself as Duane Laflotte and I delivered our popular Hacker vs. Hacker session. I showed a technique that crashes the hacker's computer when they try to brute force a web site (not for the faint of heart) and the very popular and legitimate question of whether it is prudent to antagonize the hacker.
Anyone who has met me probably can predict that I deliver a resounding hell yes to that question. I don't believe that someone already seeking to attack me (in any regard) is worthy of my backing down. They are already throwing the first punch. I want to go for a kill if I can. Bullies fear those who stand up for themselves and hackers fear those who will prosecute them to the fullest extent of the law. If I lose then the hacker has just done what I expect they would have done without my intervention, but if I win then they do to prison, lose their job and maybe get banned from ever using technology again. I call that a bad bet on their part.
No surprise, this is exactly my take on terrorists as well. You either belive that killing 50 terrorists produces 55 or you don't (in which case it means 50 fewer terrorist). Put me in the don't column. I think that people who partake in either of these activities are not stable in many regards. We occasionally get a glimpse of a hacker or terrorist who is completely rational by all other appearance, but this is rare.
Don't be afraid to vehemently and vengefully defend your turf. You won't ever seeing an attacker decide that you are too peaceful and cooperative to attack.
Monday, August 29, 2005
For a week or so...
Sony is now providing an update to their PSP game system that provides a web browser most likely because hackers have been finding ways to enable web browsing on their own. It is a smart move, but it certainly won't stop users from reverse engineering every single aspect of the system. What it does for Sony is provides them some good will by providing what users will get eventually anyways.
A primary tenet of leadership is to never give an order that won't be obeyed, it just makes you look like an idiot.
It will be interesting to see what Sony's next move is in this game of cat and mouse.
Sunday, August 21, 2005
A classmate of mine from West Point, LTC Erik Kurilla, was wounded (shot 3 times it seems) while serving as a combat commander in Iraq. While I rarely (almost never) bring personal stuff into my blog and as you will see I will weave this a bit toward my favorite subject of security, but I felt I had to say something here.
If you read the writeup it is pretty amazing when we read that, "The Commander of Deuce Four, LTC Erik Kurilla, was shot three times in combat yesterday in front of my eyes. Despite being seriously wounded, LTC Kurilla immediately rejoined the intense and close-quarter fight that ended in hand-to-hand combat. LTC Kurilla continued to direct his men until a medic gave him morphine and the men took him away.". I haven't seen Erik for a while, but he is a stand up guy who has always been very serious about every mission he gets. If I am reminded about any lesson here it is that when we get a setback or even a catastrophe, we have to keep our heads and not make it worse. If you flail, you fail.
Being in the service helped me immensely in dealing with security because it is the same mindset (though the military consequences are much more intense I have to admit). You have to re-evaluate every time the situation changes and that could be minute by minute. Erik could easily have just rolled over once he was hit and let someone else direct the battle or do the fighting, but he determined that he was still required and still able (though God knows how) so he made the call.
My info says that Erik is OK and is already back stateside. It was not my intention to stir up political debate with this post, but to show the kinds of people I look to for my inspiration when I think about protecting resources. I believe that the wars we fight will and are extending into cyberspace faster than most people think. Ultimately the courage to do the harder right rather than the easier wrong is easiest to find when we are reminded regularly of the immense sacrifices and miraculous bravery of people like Erik Kurilla. I am proud to know him and regret that I haven't seen him in so many years and didn't get know him nearly as well as I would have liked while we were at school together.
Erik, get well soon and thanks!
Wednesday, August 17, 2005
I know there is alot of information about Phishing attacks (attempts to trick users into logging into fake sites with credentials for things like ebay or paypal), but I am seeing more and more sophisticated attacks and felt that I had to raise the warning again. In our company and those clients who listen to our advice, it is a general practice to remind the staff of anything important from time to time, such as virus warnings in case people's guard has fallen or there is a new twist on attack vectors.
In that spirit, when I see a more potent phishing attack I think it is wise to remind people about the hazards.
The message that caught my attention and spawned this post invited me to "Verify your PayPal Account" in the subject. As I had just messed with PayPal, I was particularly vulnerable, just as an employee whose brother was on vacation would likely succumb to something spoofing him that said, "see the photos" (from an actual client case). Being very wary of anything online (or otherwise), I examined the actual destination of the link that looked like it would take me to "https//www.paypal.com/login" and noticed that the link actually pointed me to http://paypal.com.login-user488.info/login" (URL changed slightly to protect the innocent and not aid the guilty). At first glance you might not notice that the domain isn't paypal.com, but is actually login-user488.info. This could be a very painful mistake for the user who goes to this page and types in their paypal credentials which are likely linked to their credit card. This is the online equivalent of using a fake cash machine and punching in your PIN for the bad guys to harvest later.
The moral of this story is to be wary even of emails you expect as the attacker might just be lucky to hit you at the time you expect their kind of luring message. It is a very costly mistake. In most email clients such as Outlook you can see where a link points by just holding the mouse cursor over the link without doing any clicking. A better practice is to open up the browser yourself and type the address of the site yourself and then you know you are going where you think you are going.
If you wish to stay up to date on phishing attacks I will do my best to bring up reminders from time to time, but you should also check regularly on Duane Laflotte's blog as in the process of running our security practice at CriticalSites, he tends to see ALOT of these.
Tuesday, August 16, 2005
I have started to encounter more and more instances where companies want to get out of the business of hosting websites themselves and since the price of outsourced web hosting has dropped the use of shared and dedicated server hosting has accelerated. There are many security as well as non-security related factors that should go into the decision on which approach is best for your application and I wanted to summarize them here.
I realize that to many people this is not news, but I am finding all too often that for a large part of the population this is a new insight so I intend to occasionally provide basic info as well as any advanced data that I can provide on both security and the growing practice of hosting sites with 3rd parties.
A 3rd party hosting company can afford to maintain servers at a fraction of the cost that anyone in any other business can manage. When you sign up for a web hosting company to put your site on their server you are typically looking at a very low price (under $20 per month and sometimes under $5 per month) and in these cases the web hosting company is actually not using a dedicated server for your site. If they were then they would be out of business very soon. The fact is that in this situation you are signing up for shared hosting and that means that your website might me one of dozens or even hundreds of other web sites hosted on that same server. The advantages of this model of course is the price. You could never get a dedicated server for the same price (they typically run over $100 per month for the bare bones package and can run into the thousands per month depending on the bells and whistles you require). The disadvantages of shared hosting are more numerous in my opinion than the advantages. On a Shared Hosting plan you cannot install any software that isn't already part of the package, you might be sharing the same IP address as many other sites and the server is distinguishing requests by address once they arrive at the server, and most importantly if someone on the same server as you compromises the server with their web application (in the case of dynamic code) then your site is going to be dragged down too.
This isn't an attempt to completely scare you off of Shared Hosting solutions, but be warned about the disadvantages before you jump at the price. I use shared hosting of simple sites that I consider low security, for everything else I go Dedicated Server all the way. I see efforts to save money or time as the most common sources of bad judgement calls that undermine security.
Wednesday, August 10, 2005
It is no secret to anyone who knows me or has heard me speak on the subject of security that I have learned quite a bit of my way of thinking about computer and Internet security while serving in the military and while attending the United States Military Academy (West Point). I tend to think of securing a web application as a battle or campaign. I want to destroy the hacker for daring to cross the line of departure. As a result I have drawn heavily from the classics of military strategy and wanted to share a couple of titles with you. I will spare you the references that are wholely obvious such as Sun Tzu's "The Art of War" and "The Book of Five Rings" while also stepping gingerly around the more heavy reads such as Clauswitz's "On War". I do suggest you read those if they peak your interest, but I think there are two books that should be read by everyone who seeks to have a deeper understanding. The first is called the "Defense of Duffer's Drift" and is a great introduction to defensive tactics written in a unique and entertaining style. A friend of mine pointed me to an online version that I think is the complete text though if you like it definitely pick up a copy to read regularly. The other book is called "Lure the Tiger into the Mountains" and it is a great read about the 36 classic strategems taken from Chinese history.
Expect some comments about and from these books in the future here on my blog. Some of you may already know that Duane Laflotte and I are planning to write a book and our plan is to mimic the format to some extent of the Defense of Duffer's Drift.
Monday, August 08, 2005
Windows 2003 Server Pack 1 has a new capability that you might want to look into called Quarantine VPN.
With this technique you can validate that all clients that connect to your VPN meet specific requirements before they actually get access to network resources. Microsoft has been doing this on their network for quite a while now and they have finally given everyone else that uses their products the same capability.
For details on how to implement it and a more in depth overview on Quarantine VPN read this Technet article.
Thursday, August 04, 2005
The concept of Least Privilege is applied to developers and software testers all the time to advocate that the application be developed and tested using the lowest privileged account possible to get the job done. For our purposes (network administration), I am referring to using administrative accounts for administration only and regular user accounts for everything else including word processing, research (aka web browsing) or the ever popular solitaire!
This is about using the proper tool for the job. If you wanted to trim some leaves from a tree you would be thought a bit odd if you decided to use a chainsaw, especially if the same job could be done easily with a pair of scissors. Why is this something almost everyone recognizes as inappropriate? Because the potential for you to do damage is huge! There are certainly people out there who will be able to perform the task with the excessive firepower and not lose a limb, but why take the risk? As an administrator, hitting the delete key by accident and inadvertently accepting the confirmation becomes a major problem as the odds of you having the rights to carry out the delete are much higher then if you were logged in as a normal user. When you delete a directory on a network share you can’t just go to the recycling bin on your client machine to undo the damage. Administrators even have the ability to change the permissions at the root of a system volume which will usually render the operating system unusable (requires a restore or rebuild). Why would you want to have these unnecessary risks when it could cost days of downtime. Claims that it is inconvenient to keep track of two logins are the most common justification. Now that network operating systems have tools like the Windows “Run As” this is a hollow excuse.
See developers and network professionals are that different after all!
Monday, August 01, 2005
A recent article on Wired talks about hacking hotel systems, but what I think is more important is the line that says how everyone assumes that IR remotes are secure. I can say with conviction that these kinds of assumptions account for virtually all of the lapses in security I encounter in my travels. Assumption is death when it comes to security in everything from preventing SQL Injection to ensuring you locked the doors at night.
Think about your assumptions.
Tuesday, July 26, 2005
I have spent alot of time recently talking about passwords and I think the reason that I can't seem to get off the subject is that there is so much that has to change about the way passwords are actually handled by companies. Most recently I had a discussion that caused me to poll several clients about how they tracked who knew each of the myriad passwords in their organization. The resounding and unanimous answer was, "oh maybe we should do that".
If you know who knows each password (even if you don't document the passwords) then you have a much better chance of getting access to the system you need, when access is needed most. Also by tracking the names of everyone who has ever been told the password to your Cisco Router for instance then when Joe leaves the company at least you have some justification for deciding not to change that password aside from it being too hard to bother.
You will find that people get much less freaked out then you might think when you start maintaining a document that shows who knows each of the passwords you care about. You will be surprised at just how big the list becomes if you put any effort at all into it. This practice not only serves the purposes I have already pointed to, but it also helps you avoid that really scary situation when you have to call an ex-employee and ask them if they remember the password to a critical system.
Expect more food for thought on passwords as I am becoming convinced that it is a bottomless pit of best practices that noone seems to be practicing.
Friday, July 15, 2005
I am seeing the signs that the Security business is going through a consolidation as some of the bigger names buy up smaller firms to cover their bases. Most recently, VeriSign bought iDefense for $40 Million
. I don't think this is THE consolidation as there are many, many more security plays yet to occur (we aren't quite done with security as it hasn't become a solution yet), but it is interesting to see the giants scramble. Let the bidding begin...
Monday, May 30, 2005
Just recently I talked about online password security and I referred to the way most sites on the Internet handle passwords as the Ugly in my “the Good, the Bad and the Ugly” slide. Most sites I visit not only allow me to put in a woefully weak password, but don't allow me to set a strong one by my standards. Have you ever seen a website support pass-phrases by allowing really long passwords (say 50 or more characters)? Probably not.
So given my pessimism, I think the message is getting through. On a site called GamerFacts.net there is a post about the change in policy that Sony has made to their existing system that supports massive multiplayer online RPG games like Everquest and Star Wars Galaxies. To see the post and read the message sent out by Sony click here.
Lets hope this is just the tip of the iceberg.
Friday, May 27, 2005
A customer said today that they are using stored procedures so unless I knew of any other SQL Injection risks then they thought that was enough. The truth is that the answer is that this is true in most people's minds. The problem is that this common mindset is exactly the kind of thing that aids hackers.
While using stored procedures or parameterized queries or any of the other methods to thwart hackers is not only highly recommended, but also an absolute requirement, I don't feel it is enough. We are treating the symptoms, not the disease. If a hacker fails in their SQL Injection attack because of these measures then great, but we haven't prevented them from trying something else.
Think about having the application try to detect such attacks even if you are impervious (which you probably aren't in my experience) and when you detect this kind of attack then do something to hinder the hacker. Close their session, ban their host, crash their browser, whatever you can do to make it harder for them to move to the next step of their attack will ultimately help you.
I will discuss this topic more in future posts as I think there is alot left to say on it, but for the moment look at your existing web application in this light and see what you come up with.
Thursday, May 26, 2005
The stereotype of the malware and spyware author is the lone disgruntled hacker who has squandered their talent on rage and hate. Sounds like the perfect villian for a melodrama. It turns out that the truth is much worse. The driving force behind most of this software is actually organized crime. An article on ZDnet yesterday details how this all works in a nice little overview. This seems to be just another wave in the process of hacking and anti-hacking becoming battles not between individuals alone in the dark, but between industries and governments vs. syndicates.
Tuesday, May 24, 2005
I just read an article which quotes Jesper Johansson as saying that we should reverse the long held truism that users should not write their passwords down for their own reference. Jesper is a well respected (though often contreversial) Security Heavyweight who has worked for Microsoft for some years. I know Jesper from events we both presented at such as TechEd Hong Kong and the New York Security Summit a year or so ago. I often read his advice and take it to heart, but this time I think we need to be less binary. I can see circumstances where you can make this case, but to just reverse the rule is reckless. We need training first and foremost. Have I seen a seasoned professional make this method of password tracking work. Yes, I have. But I have also seen users abuse the hell out of the loosening of such policies.
Silver bullets are few and far between in our space when it comes to security. We have trained most drivers to lock their car and carry the key along with them (don't even attempt the keyless entry system argument, that is newish and doesn't weaken my analogy). If you lock the key in your car or lose it then the world takes a healthy bite out of your convieniece factor in terms of cost and delay. If we just trained users to take their passwords as seriously then I think we would be OK.
I recently returned from Huntsville, Alabama where I gave a talk on passwords for developers. The article cites systems that allow only weak (read short and limited character set) passwords to be used. The number of examples of this from the web is staggering so I won't bother. We need to go after this problem as well. Developers (and managers) don't get that there are brute force attacks against web site logins just like there are for PC Operating System logins. They are much more mature than most people think.
My bottom line is that I don't think you can make a blanket statement about something this nuanced and varied by group. I give credit to Jesper for saying shocking things to promote the debate (he has accomplished that), but I can't buy in that we have a new and diametrically opposed truism to our old and long held on that users should not write down their passwords.
Friday, March 11, 2005
A recent article about terrorists being behind continued attacks on our energy companies in an attempt to disrupt the power grid made me realize that this should serve as a wake up call for the rest of us. If you are running a business related web site in the US or one of its allies you have to think about what happens if the bad guys decide to go for the softer targets. Remember when bad relations with China released a wave (almost a plague) of defacement hacks against US based web site?
When you read a story like this, just think about what the hacker with a political agenda might turn toward if they get too frustrated (and I hope they do get very frustrated) hacking at our vital national interests.
Monday, February 28, 2005
For those of you that don't know, a big concern in companies vulnerable to corporate espionage (almost everybody) is employees walking away with a USB drive full of confidential data. Device Lock has solved this problem for several of our clients and they have just released a new version.
If you haven't see this before at least check it out.
Monday, February 07, 2005
In case some of you have noticed recently there was an article on zdnet (not my favorite publication anyways) that quoted James Gosling, Sun's CTO, stating that “Microsoft's decision to support C and C++ in the common language runtime in .Net one of the "biggest and most offensive mistakes that they could have made"“.
I figured that I would share what has to be the best reponse to this statement by pointing people to Don Box's reply on his blog.
Now, don't get me wrong, I am all for people raising the alarm when we have a security problem, but to make generalized and unfounded comments like this when we have so much in the area of security to worry about is just a waste of our time.
Monday, January 10, 2005
If you use Internet Explorer then you should pay close attention to this...
An exploit to security holes in Internet Explorer (even if you have XP SP2 installed) has been posted by a group called GreyHats. They are not happy that MS has not fixed the exploits since they were made known in October 2004 and figured they can increase the speed of a patch, but in the process I expect they will only succeed in screwing alot of innocents.
If you run with least privledge then life is much better for you then if you run as an administrator on your web surfing box. Either way I suggest you vist the test page provided by Secunia and see the likely bad news.
If you are vulnerable, be careful where you go between now and when you install whatever patch comes out.
Thursday, December 23, 2004
It seems to hold true that any tool can have a good and a bad use. In a recent attacks, Google was used as a support mechanism for spreading a virus and defacing web sites.
While there isn't anyone who can guarentee that a particular package or product won't be vulnerable, it does pay to ensure that whoever you get your software from has a track record or providing patches quickly when this kind of thing occurs. If not then make sure you figure out how you will patch the stuff yourself.
Monday, December 20, 2004
A recent article about a security flaw in the new Google Desktop Beta should serve as another reminder that you should never use beta software on production machines. The rule for me has always gone that if I would be upset by a total rebuild of the box, then only tested and finished software should be installed. I admit that I love the new stuff myself, but if you dance with the devil don't be surprised if you get burned.
Tuesday, December 14, 2004
MS has made available a preview of the Member Management Component that you can use to build into .Net 1.1 sample applications. It isn't exactly what will be released with VS.Net 2005, but it gives you something to play with so you can get used to the new model.
Be advised that it seems that it doesn't seem to be licensed for production use. If that interpretation is correct then it means that this is just something to play with in advance of VS.Net 2005 and can't be built into any real applications.
Monday, December 06, 2004
Who owns the passwords that you or your users use to access your network or application?
If you don't know, then you have a problem. Your users hopefully memorize their passwords, but therein lies the rub. If an accountant has gone to the trouble of memorizing a complex password then they are very likely to be tempted to use that password for other systems. Maybe the corner hardware store's web site requires registration. If they use the same username and password that works on your systems and top it off with entering the company email address then your security now depends on the security of the corner hardware store's web site security (provided it isn't actually run by a hacker)!
Tell your users in writing that the passwords they use at work are company property and must not be used on any other systems. Put it in writing like any other company policy and ensure they know that failure to comply is a terminable offense (and mean it). If you don't then forget about security, it won't help you in the end.
Monday, November 29, 2004
But the stakes have been raised in the last year. Now messing up your companies security has legal consequences that start out with fines and can go all the way up to criminal liability and jail time!
Friday, November 12, 2004
Dell has launched a website designed to help small businesses deal with all the security challenges. The site seems good, but the performance was so bad at one point that I can't decide whether that means it is a resounding success or a dismal failure.
It is very much aimed at selling more product. When you click on the spyware link it doesn't mention any of the free products that solve the problem, just the ones you can buy from Dell.
The sites advice is a bit behind the times (doesn't mention pass phrases under the password section), but if you just want to point someone to a place where they can self help on security using a name they will likely trust then this might be a useful link.
Tuesday, November 02, 2004
A common bit of advice bandied about lately (by Jesper Johansson of MS, me, and others in and out of MS) is to turn off LM Hashes on your Windows systems and networks. This is great advice, but there is a proviso. Some things depend on LM Hashes to work. Most of them are not an issue, like the fact that Windows 95 and Windows 98 shares stop working. I don't recommend using Windows 95/98 as file servers anyways. The problem is that Windows Clustering stops working. This is a big one. I realized recently that the knowledge base article that describes how to deal with this small wrinkle got “archived” by MS and was therefore unavailable. I did some digging and as of today the article has been reinstated due to my prodding.
So, this post is to welcome KB article 828861 back to the land of the living and to make sure everyone knows how to find it for reference. The advice in it is quite straight forward, but it always helps to point bosses or clients to words written by the platform vendor.
Happy LM Hash Free Clustering!
Wednesday, September 29, 2004
Often we don't know we are in danger until we get clobbered. We have all had that feeling in the pit of our stomachs after something heavy falls where we were standing a few minutes ago. In the middle ages ignorance of disease killed many and the same is true of most in the modern world of computer security.
You can't defend against these things:
- Attacks when you don't know how they are done
- Attacks to which you don't know you are vulnerable
- Attacks you don't realize are possible
Make an effort to stay up to date with exploits (preaching to the choir no doubt), so you don't get nailed.
Friday, September 24, 2004
Now there is an even more dangerous exploit for jpg files. Details can be found here.
I have seen an example of this exploit in action. In the demo I got from our security team, displaying the custom crafted jpg image caused the workstation to reboot.
If you didn't take the last reminder to patch seriously, I urge you to get it now.
Tuesday, September 14, 2004
Now I have heard it all! Terrorists, Hurricanes and now JPEGs can be used to attack your computer!
To see what I am ranting about check out the article.
Wednesday, September 08, 2004
I just finished reading an upcoming article from Forbes Magazine (unfortunately you will have to register to read it before the September 20th pub date) about the belief that terrorists are turning to hacking as their next major vehicle to do damage.
In the article they point out things like, “The FBI says the cyberterrorism threat to the U.S. is "rapidly expanding." "Terrorist groups have shown a clear interest in developing basic hacking tools, and the FBI predicts that terrorist groups will either develop or hire hackers," Keith Lourdeau, an FBI deputy assistant director, told the U.S. Senate earlier this year.”
The article also mentions a company that I have had dealings with in my consultant travels. Invensys makes valves and regulators and such. Exactly the kind of equipment that a bad guy would want to manipulate.
Scary, but maybe I'm not too old to get back in the service after all...
Tuesday, September 07, 2004
The Software Development Life Cycle (SDLC) is a well established and well thought out concept. There are books and experts and cool slides galore that talk about it and how security should fit into it. The problem that I see is that the process as most people think about it isn't cyclical enough.
Most of the treatment of the subject shows the process ends on acceptance of the product. This means that it is in general use, the major bugs that will be fixed have been and the users are active with the application. This status remains until the application is either revised or retired. You can't live that way anymore. If you have an application that is waiting for a revision in the future or making its way to retirement, I would be willing to bet that it has already outlived any security analysis done during its construction. How many new threats exist today that weren't around when existing applications were being developed. How many measures were taken as fully adequate just a year ago that we now see still leave us in the lurch against a determined attack?
If you have an application in production that hasn't been revised for security in some time you may want to at least take a mental inventory. The C levels in your company won't understand that your application was secure when you released it. They will only see that it was not secure when it was attacked.
Thursday, September 02, 2004
I am listening to the Don Kiely interview on Dot Net Rocks and thought that it was worth pointing the security minded toward. I have known Don for a while from conferences out and about, but hadn't realized how much he has delved into the Least Priviledge issue until listening to Carl and Rory discuss it with him on the show.
Also highlighted was Ted Neward's article on least priviledge located on theServerSide.Net which though short has spawned some comments that show the mood on the subject.
Even if you don't take the advice at least know the issue.
Wednesday, September 01, 2004
If you haven't used it yet then you should get to know this tool. If you have then you should be happy to know that the final 1.0 version of AuthDiag is now available at http://download.microsoft.com/download/6/c/9/6c96682c-8449-4112-a089-3b98c0035d0c/AuthDiag.msi
When you are using Windows Authentication for a web site it can be mind numbing to figure out what is causing access denied problems, especially if you aren't a security expert. While it is an unsupported tool, it usually provides enough to get you past your access control configuration issues.
This link is to the i386, 32 bit version of the application. If you need a 64 bit version (there are different installers for AMD and Intel 64 bit chips) drop me a line and I will hunt down the URLs for you.
Friday, August 20, 2004
I was talking to an old friend at the recent Mobility Day held at the Microsoft Office near Boston and he brought up an incident that I have seen happen to others. I realized though that it isn't something talked about often so it seemed like perfect blog fodder.
He told me of working with a large bank in Boston (that doesn't really narrow the list down) where outsourcing was literally a requirement based on the budget. The code for the bank system was developed by a Russian firm that showed great talent. Unfortunately they also showed great talent for deciet. The code delivered had 3 backdoors in it that would have allowed easy access to account data and possibly to money. After ripping out the offending code after doing a very wise line by line code review the system was deemed safe. How often has this happened without it being caught? The X-Files premise, “Trust No One“ is actually correct. I don't mean to indicate that only off-shore firms would do this, quite the contrary, but I think the odds go up based on how subject to prosecution the developers would find themselves if discovered.
This also brings up what I think is the biggest fantasy of all. The one that asserts that open source code is inherently more secure than commercial software. We have examples from the last 12 months where some of our selfless open source contributors were not so selfless after all. It should be no secret based on the main subject of my entire blog that I think that security is the place where all the action will be in the next 5 years. This translates to where all the cost will be as well.
My point is that you must truely Trust No One. If you decide to use open source because it is cheaper then you are deluding yourself unless you include the cost of doing a complete, line by line code review before implementing it. The advantage of using commercial / proprietary products is that if you buy it from a company and you make sure it is one that you can sue for enough money to matter if they put in a backdoor, then that is your hedge against the threat. Always ask yourself the question of what is preventing this developer from putting in a backdoor.
Tuesday, August 10, 2004
We regularly do network and application reviews for customers to make sure they know where the security problems are hiding. I kind of expect to find servers unpatched, applications accepting unvalidated user input and the raft of standard security faux pas on both the network administrator and developer sides of the house. What get me everytime is when I see physical security ignored or given token attention.
I was once teaching a class on SQL Server when a student jumped up and ran from the room, not to be seen again for 2 days. I asked what I had said wrong and was told that 16 of his servers had been stolen out of their datacenter. The datacenter in question had been on the 1st floor and had windows that the theives broke and took the machines at their leisure. This is an extreme case and it happened back when SQL Server 6.5 was still a new product, but you would be surprised how many companies are still largely ignoring physical security.
Over 50% of hacking is done from the inside. Physical possession is the ultimate vulnerability. Unless your system is secured far beyond what is customary using technologies like encrypted file systems, anti-tampering devices and the like, then tools like Lophtcrack will give up the goods in a relatively short period of time.
Take another look at your physical security. You might have a really solid server room with a locked door, but if the hinged can be removed from the outside, how is that going to deter the soon to be ex-employee from liberating a server over the weekend.
In our company we send out emails at intervals to the staff reminding them of how to avoid unleashing a virus on the network. We do this before we get nailed by the latest in exploits. I suggest you remind yourself and your staff about physical security in the same way. Regularly and proactively, the job you save may be your own!
If you have a physical security horror story you would like to share then please share via the comments.
Wednesday, July 14, 2004
In case you need a way to clean up after getting hit by the Download.Ject exploit...
Download.Ject malware removal tool released
- Monitoring Internet access. When the user visits one of several financial or ISP Web sites, the Trojan captures sensitive information—such as log-in names, passwords, and so on—and sends it to a Web server for the Trojan’s author to retrieve. Installing a proxy server that allows the user’s system to be used as a relay for such actions as sending spam. Opening fake dialog boxes that prompt the user to enter confidential information such as ATM card codes, credit card numbers, and so on. This information is then sent to a Web server for the Trojan’s author to retrieve.
Microsoft has released a tool to help you remove Backdoor:W32/Berbew Trojan variants from your computer. You can download this tool from the Microsoft Download Center and run it on your computer to remove Backdoor:W32/Berbew.A, Backdoor:W32/Berbew.B, Backdoor:W32/Berbew.C, and Backdoor:W32/Berbew.D, Backdoor:W32/Berbew.E, Backdoor:W32/Berbew.F, Backdoor:W32/Berbew.G and Backdoor:W32/Berbew.H infections.
This tool is discussed in Microsoft Knowledge Base article 873018. This KB can be found here:
Use it in good health.
Friday, July 09, 2004
Someone recently sent me a link to an MSDN article about 10 must have tools. While looking it over I saw The Regulator listed and started thinking about validation of client data.
Everyone has by now heard that you must validate your data from a client before you act on it, but what does that mean. It doesn't mean that you just put a maximum length on your input box in your HTML and call it done. That is no security at all. Instead you have to do server side checks against what you expected to recieve from the client. If you then want to go the extra measure and strip out dangerous characters after that then enjoy! You can't catch everything with this latter approach. Take this example. Suppose you have a page that takes a value and uses it in the where clause of a dynamic SQL Statement (you shouldn't of course, but people still do). Now you want to avoid SQL Injection and for some reason have ruled out parameterized queries using ADO.Net. Given this classic SQL Injection vulnerable scenario, suppose you are trying to defend against the string like: ' OR 1=1 --
Single quotes are easy to strip out and in some cases you can even look for the OR as a literal string. Suppose further that you have a field that asks for age and uses that to execute our dynamic SQL query. The shrewd (or maybe just lucky) hacker can put in: O'R 1=1 --
Now this won't destroy your server, but I am trying to prove a point, not educate hackers. If your home grown script to kill SQL Injection like characters checks for the literal OR it will find that it isn't present. The single quote defeats that check, but it also breaks the OR. If your next move is to strip out single quotes then your own defenses fix the hacker's statement. Also since the datatype of the field isn't text, I don't need the single quote anyways, that was just a way to put in a character to hide my OR and that you will strip out for me. This can be done in billions of ways depending on your order of operations. What this proves is what Erik Olsen of Microsoft has said in the past and I agree with totally, namely, YOU CAN'T ENSURE SOMETHING ISN'T WHAT YOU WANT, ONLY THAT IT IS WHAT YOU WANT. If I expect an zip code from inside the United States then I check that the value is 5 characters, all of them digits. Done, I know it is what I expected and can now move on. If you have to strip something bad out of user data then maybe you shouldn't strip it out, but instead should reject the request completely?
If any of this sounds reasonable then you really have to get going on your RegEx skills and that brings us back to the utilities list. Try The Regulator, find something else, write your own or just learn the RegEx syntax.
Friday, July 02, 2004
KB Article explains how to deal with Download.Ject exploit.
Monday, June 28, 2004
I have recently been asked by a deeply knowledgable friend of mine, Malek Kemmou, about the latest in Intrusion Detection software. I realized that if he was curious, then this might be a topic worthy of a few words...
The bad news is that there is not much out there really that can serve as a silver bullet. Alot like the Anti-spam software when it first started coming out, there were alot of players, but they all used the same basic technique. In the case of detection software we are in much the same place. Hackers leave footprints if you are logging (both on the OS itself and on the web server). If the logs are not configured or configured incorrectly then it is like having video cameras without film, they won't help you solve the crime.
A further problem is that more elite hackers tend to alter the logs after they are done (wiping the gun clean so to speak). Step 3 (step 1 is to turn on logging, step 2 is to configure it appropriately) is to secure the logs from being altered (or dumped) by an intruder.
Products like GFI LanGuard will publish white papers (see the link) on why they are the best, but mostly they are the same. You could interpret most logs yourself until they get beyond a certain size.
You can even just submit your logs to DShield.org (been around since Nov 2000) and they will analyze them for you. Some interesting statistics come out of looking at the data from so many firewalls and web servers. If you go there note that they are currently reporting Survival Times of 22 minutes (The "Survival Time" is the average time between attacks for our average submitter. An unpatched PC will survive about that long before it will be infected with the worm of the day).
Here is a nice little article from the guys at Foundstone, http://secinf.net/info/misc/tricks.html, that should give you some tips on what you (and the detection software) should look for beyond the obvious "cmd.exe" in your standard IIS logs.
If you are using something you like, let me know, I expect this space to get pretty heated in the next 18 months as awareness rises and drives demand.
Wednesday, June 16, 2004
If you feel the need to host ASP.Net on a windows domain controller and can't bring yourself to upgrade to version 1.1 then at least read this KB article.
Tuesday, June 15, 2004
Cookbook for frustrating hackers attempts to use the Administrator to hack.
Thursday, June 10, 2004
Time to either upgrade your WSE knowledge or get some!