From Source to Secure : Security

Follow-up from previous SQL Injection post.

RockyH — Mon, 21 Dec 2009 03:29:00 GMT

So first off, Thank you to Jim Manico for his comment on my previous post which lead me to create this post. I will includes quotes from Jim’s comment for reference here.

JM: “I think you are terribly wrong, and its important we clear this up.”

No worries I appreciate your candour. Everyone is entitled to their opinion..

I’ll stick to OWASP references since OWASP is near and dear to Jim’s heart, aside from the fact that OWASP is a great reference in general. (Side note, for those of you that do not know Jim, he works for Aspect Security and does the OWASP Podcast Series http://www.owasp.org/index.php/OWASP_Podcast )

According to the OWASP top 10, Injection Flaws ‘particularly SQL injection’ is the #1 most common problem. Why? Because people are using Dynamic SQL. Strongly typed parameterised stored procedures would have solved almost all of these SQL injection attacks. A correctly implemented parameterised stored procedure is not vulnerable to SQL Injection. So if people were using them, SQL Injection wouldn’t be #1 on the IT Security Most Wanted list. But because people keep thinking that it’s ok to use Dynamic SQL (which again is SQL queries based on string concatenation at runtime) it is still one of the most widely used attack vectors for the bad guys.

For those of you just joining us, by Dynamic SQL I am referring to the common industry definition where Dynamic SQL statements are the ones that are created by string concatenation at runtime. For example:

private void cmdLogin_Click(object sender, System.EventArgs e) {

string strCnx =

"server=localhost;database=northwind;uid=sa;pwd=;";

SqlConnection cnx = new SqlConnection(strCnx);

cnx.Open();

//This code is susceptible to SQL injection attacks.

string strQry = "SELECT Count(*) FROM Users WHERE UserName='" +

txtUser.Text + "' AND Password='" + txtPassword.Text + "'";

int intRecs;

SqlCommand cmd = new SqlCommand(strQry, cnx);

intRecs = (int) cmd.ExecuteScalar();

if (intRecs>0) {

FormsAuthentication.RedirectFromLoginPage(txtUser.Text, false);

}

else {

lblMsg.Text = "Login attempt failed.";

}

cnx.Close();

}

From the Data Security Blog

In the previous post/response I listed a plethora of industry references that support avoiding Dynamic SQL.

JM: “Dynamic SQL is important. For example, when you use parametrized queries against tables with VERY [RH large] row size [count] (many millions) against some vendors, its actually KILLS performance. Some features, like advanced search, are often so complex that they beg for dynamic SQL.”

In very rare cases, yes dynamic sql may be unavoidable. Ironically enough, a customer of mine said exactly the same thing. They said that they absolutely had to use Dynamic SQL. And refused to listen when we told them it was a bad idea We said if you really really must use it, you need to do input validation, strongly type the inputs etc. etc. 3 months after we left, they were breached through a SQL Injection vulnerability on a Dynamic SQL Statement that we had told them to fix.

But enough of the first-hand experience stuff…

What does OWASP say you should do to avoid SQL Injection? Here it is:

From: http://www.owasp.org/index.php/Top_10_2007-A2

Avoid the use of interpreters when possible. If you must invoke an interpreter, the key method to avoid injections is the use of safe APIs, such as strongly typed parameterized queries and object relational mapping (ORM) libraries that are immune to injection (be careful here - Hibernate, for example is NOT immune to injection by itself. You have to use named parameters to be safe in Hibernate). These interfaces handle all data escaping, or do not require escaping. Note that while safe interfaces solve the problem, validation is still recommended in order to detect attacks.

Using interpreters is dangerous, so it's worth it to take extra care, such as the following:

Input validation. Use a standard input validation mechanism to validate all input data for length, type, syntax, and business rules before accepting the data to be displayed or stored. Use an "accept known good" validation strategy. Reject invalid input rather than attempting to sanitize potentially hostile data. Do not forget that error messages might also include invalid data

Use strongly typed parameterized query APIs with placeholder substitution markers, even when calling stored procedures

Enforce least privilege when connecting to databases and other backend systems

Avoid detailed error messages that are useful to an attacker

Show care when using stored procedures since they are generally safe from SQL Injection. However, be careful as they can be injectable (such as via the use of exec() or concatenating arguments within the stored procedure)

Do not use dynamic query interfaces (such as mysql_query() or similar)

Do not use simple escaping functions, such as PHP's addslashes() or character replacement functions like str_replace("'", ""). These are weak and have been successfully exploited by attackers. For PHP, use mysql_real_escape_string() if using MySQL, or preferably use PDO which does not require escaping

When using simple escape mechanisms, note that simple escaping functions cannot escape table names! Table names must be legal SQL, and thus are completely unsuitable for user supplied input

Watch out for canonicalization errors. Inputs must be decoded and canonicalized to the application's current internal representation before being validated. Make sure that your application does not decode the same input twice. Such errors could be used to bypass whitelist schemes by introducing dangerous inputs after they have been checked

Language specific recommendations:

Java EE - use strongly typed PreparedStatement, or ORMs such as Spring or named parameters within Hibernate.

.NET - use strongly typed parameterized queries, such as SqlCommand with SqlParameter, or named parameters within Hibernate.

PHP - use PDO with strongly typed parameterized queries (using bindParam()).

So just to see if we’re on the same page:

JM: “When you build your queries, you just need to do vendor-specific escaping of your inputs (plus some other validation, like cannonicalization and size checking) while dynamically adding that user data to queries. “

OWASP Says:

“Do not use simple escaping functions, such as PHP's addslashes() or character replacement functions like str_replace("'", ""). These are weak and have been successfully exploited by attackers. For PHP, use mysql_real_escape_string() if using MySQL, or preferably use PDO which does not require escaping”

Now I imagine Jim’s character escaping is perfect but history has shown us that all escaping does for that kind of stuff is give you a false sense of security. Anyone interested in bypassing character escaping should read either of Litchfield’s books on database hacking, or any SQL Injection attacker advice. They both show that it is easy to bypass character escaping.

One of the reasons this fails is because character escaping normally relies on black lists to identify and replace (escape) the characters. Blacklisting by its very nature is very limited and you can never be sure you get every possible bad character into the list.

So now that we have the basics out of the way, let’s get to the crux of the situation. People who are complaining about what I posted are complaining for the wrong reasons. But everyone loves to complain don’t they. ;-)

Had I said, “Avoid Dynamic SQL” instead of “Abandon Dynamic SQL” I wouldn’t have gotten this level of blowback. But that particular word sure stimulated some insightful debate didn’t it?

In reality I agree that there may be some instances where you simply cannot use a parameterised stored procedure to do the right thing. There may be some strange circumstances where you are forced into using Dynamic SQL. I would guess that this is likely to be less than 5% of all database calls a developer will make in a lifetime. But hey, I admit there will be those times.

The problem is, as is evident by the massive number of SQL Injection vulnerabilities reported through the CVE and OWASP demonstrate, very few people get the validation and protection required to use Dynamic SQL right. If Dynamic SQL is so Okay to use, why is SQL Injection public enemy #1 according to OWASP?

The issue is that Dynamic SQL is actually very difficult to secure. It’s the same reason that you don’t use just use strncpy to avoid the problems people have with strcpy. Because people keep getting the ‘n’ part wrong. Which is why so much effort has gone into creating safe string handling functions.

Now personally, I believe that proper input validation would stop almost every attack out there. But perfect input validation is as difficult to achieve as perfect cryptography. And because you can’t implement perfect input validation, you need to apply defence in depth. If you use parameterised stored procedures behind your input validation, even if your input validation fails, you are still immune to SQL injection attacks. Whereas if you are using Dynamic SQL, if your input validation fails you are a victim.

JM: “There are many ways to skin a SQL cat, and we want to make sure that as security professionals we help master techniques that work they way THEY do it, instead of exclusively making them do it our way.”

I agree with you on the fact that there are many ways to skin the SQL Cat. You can create calls to a database in many different ways. But, you should always use properly created parameterised stored procedures unless there is absolutely no way to avoid it. Then look at the other ways.

As far as what we should do as security professionals; I have my own opinions about this. To be honest, customers pay for us to come in and show them how to secure their applications and development procedures. They are paying us because we have the answers that they need. If all we do is water down our advice until it becomes ineffectual, we are doing the customer an injustice.

As security professionals, if our customers have some bad habits that are leading them to create vulnerable applications, we need to correct what they are doing, not water down the security advice until it allows them to continue to make mistakes. If there is a point, where the best choice for security simply can not be met, then we find a compromise such as allowing dynamic SQL in rare cases, and we apply our security scrutiny to shoring up the defences around it. But if we are serious about securing modern software, we need to consider changing the way we do things so that the best security choice IS possible rather than bending all the rules to continue to allow the bad habits to propagate.

Consider this; if you do have one of those complex or convoluted SQL Queries that you can’t convert to parameterise stored procedures, then maybe you should re-evaluate how your data is organised, and how you are retrieving the values. That might address the problem, rather than just the symptom which is the complex dynamic sql.

Again, I will reiterate that this is my opinion. I’m in the security field to change the industry so that we don’t have vulnerable software anymore. Sure in all practicality it’s a pipe dream, but if you aim for the stars even if you fall short you still made it to the moon and that is far better than where we are now.

Now, Jim I hope you did not take this personally as it was not meant that way. But you didn’t provide any facts, evidence, or references for me to address so I responded to the issues as they were presented. I always value comments especially from opinions differing from mine because I believe that the debate itself can be as enlightening as any form of instruction and I’m always eager to learn just in case I have been mis-informed.

{Edited for Typos by RH}

“there is no bigger attach vector than with a parameterized sp” NOT!!

RockyH — Thu, 17 Dec 2009 07:39:43 GMT

I recently posted an article on our ACE Team blog (you can read it here if you are interested) There were a few comments about the use of Dynamic SQL that made me realise that not everyone “get’s it” yet.

Here are the comments that started the discussion:

Alastair Upton said:

Shouldn't Rule #4 read 'Use parameterized SQL?' Dynamic SQL is perfectly fine (and it is what most ORMs use) provided that it is parameterized. It is not the use of stored procedures that protect you (as you have shown in the example) but the additional protection of parameter validation over string concatenation.

It is also important to protect the various layers of your application (e.g. implementing security on the database tier to make sure minimal rights are granted on objects).

RockyH said:

Hi Alistair,

Not really. Dynamic SQL by definition is not fine. It depends on how you are considering 'parameterized' SQL. If you are referring to parameterized stored procedures, then yes, that is the way to go but that is not dynamic SQL.

Essentially, dynamic SQL is when you build the SQL up as a string and do all of your variable/parameter substitution (either in code, or in the stored proc itself) before you send the SQL statement to the DB engine to be processed as a command string.

Now, that being said, ORMs, and NHibernate, etc. can produce good SQL, that is technically dynamic, but with proper and extensive input validation.

However these rules are aimed at developers writing code and the code that they write. Not necessarily the libraries they use. Your point is taken though. Thanks for the comment.

Daniel said:

Alastair Upton is right, RockyH is wrong. "Abandon Dynamic SQL" is a superficial and wrong statement.

For example SharePoint uses dynamic SQL excessively, and as long as you do it right (and if you do it only when you HAVE to do it, because it also may hurt perf and maintainability), with parameterized queries and optionally sp_executesql, there is no bigger attach vector than with a parameterized sp.

If you write such articles about security, at least get the facts straight.

Now, those of you that know me understand that I couldn’t just let that go… well because I’m concerned about a lost sheep is all. So I’m posting my response to this here, so that we can all make sure we understand that Parameterised Queries on Stored Procedures is THE best way to stop SQL injection attacks and why you should avoid dynamic SQL.

Hello Daniel. Thank you for your passionate response.

So just to be clear you said:

" there is no bigger attach vector than with a parameterized sp." aside from the misspelling of attack I think you are trying to say that Parameterised Stored Procedures are the biggest attack vector. Then you immediately followed with:

"If you write such articles about security, at least get the facts straight."

Excellent advice, especially considering your previous statement.

So just for the sake of getting facts straight, can you give me any examples of where a properly created (not using string concatenation and calling EXEC or sp_execsql which is vulnerable to SQL injection) parameterised stored procedure is exploited through SQL injection?

Here are some of the many many examples that describe where and why you should not use dynamic sql.

From: http://cwe.mitre.org/data/definitions/564.html

Implement SQL strings using prepared statements that bind variables. Prepared statements that do not bind variables can be vulnerable to attack.

Use vigorous white-list style checking on any user input that may be used in a SQL command. Rather than escape meta-characters, it is safest to disallow them entirely. Reason: Later use of data that have been entered in the database may neglect to escape meta-characters before use. Narrowly define the set of safe characters based on the expected value of the parameter in the request.

From: http://cwe.mitre.org/data/definitions/89.html <- This CWE definition is all about not using Dynamic SQL and properly validating input.

Process SQL queries using prepared statements, parameterized queries, or stored procedures. These features should accept parameters or variables and support strong typing. Do not dynamically construct and execute query strings within these features using "exec" or similar functionality, since you may re-introduce the possibility of SQL injection.

From: http://msdn.microsoft.com/en-us/library/ms161953.aspx

Never build Transact-SQL statements directly from user input.

Use stored procedures to validate user input.

Use Type-Safe SQL Parameters

The Parameters collection in SQL Server provides type checking and length validation. If you use the Parameters collection, input is treated as a literal value instead of as executable code

Use Parameterized Input with Stored Procedures

Use the Parameters Collection with Dynamic SQL

If you cannot use stored procedures, you can still use parameters, as shown in the following code example:

SqlDataAdapter myCommand = new SqlDataAdapter(

"SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id", conn);

SQLParameter parm = myCommand.SelectCommand.Parameters.Add("@au_id",

SqlDbType.VarChar, 11);

Parm.Value = Login.Text;

From: http://unixwiz.net/techtips/sql-injection.html#miti

Use stored procedures for database access

When the database server supports them, use stored procedures for performing access on the application's behalf, which can eliminate SQL [injection] entirely (assuming the stored procedures themselves are written properly).

From: the Microsoft SDL documentation, and quoted on Michael Howard's blog: http://blogs.msdn.com/sdl/archive/2008/05/15/giving-sql-injection-the-respect-it-deserves.aspx

Applications accessing a database must do so only using parameterized queries. (RH This is a rule at Microsoft and dynamic SQL is considered a high severity bug if found)

Creating dynamic queries using string concatenation potentially allows an attacker to execute an arbitrary query through the application. This vulnerability allows for unauthorized, interactive, logon to a SQL server which may result in the execution of malicious commands leading to the possible modification (or deletion) of Operating System or user data.

From: the SDL documentation: (and Michael Howard's blog above)

"Applications accessing databases should do so only using stored procedures. "

-and-

"Do not use "exec @sql" construct in your stored procedures.

Using stored procedures helps to mitigate the SQL injection threat to a great extent since type checking is available for parameters. If the attacker supplies input that does not match the type constraints the stored procedures will throw an exception. In the vast majority of the cases, this should be properly handled within the application.

However, if the stored procedures perform string manipulation in their code and then execute that query using the "exec @sql" construct incorrect handling of user input can produce the same SQL injection vulnerability as would be seen at the application layer."

From: http://capec.mitre.org/data/definitions/66.html (SQL Injection)

Mitigations

Strong input validation - All user-controllable input must be validated and filtered for illegal characters as well as SQL content. Keywords such as UNION, SELECT or INSERT must be filtered in addition to characters such as a single-quote(') or SQL-comments (--) based on the context in which they appear.

Use of parameterized queries or stored procedures - Parameterization causes the input to be restricted to certain domains, such as strings or integers, and any input outside such domains is considered invalid and the query fails. Note that SQL Injection is possible even in the presence of stored procedures if the eventual query is constructed dynamically.

From: http://msdn.microsoft.com/en-us/magazine/cc163917.aspx#S4 Stop SQL Injection Attacks Before They Stop You

"Avoid Dynamic SQL

The SQL injection attacks I have demonstrated in this article are all dependent on the execution of dynamic SQL—that is, SQL statements constructed by the concatenation of SQL with user-entered values. Using parameterized SQL, however, greatly reduces the hacker's ability to inject SQL into your code."

From: http://www.owasp.org/index.php/SQL_Injection

SQL injection errors occur when:

1.Data enters a program from an untrusted source.

2.The data used to dynamically construct a SQL query

From: http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

Primary Defenses

Defense Option 1: Prepared Statements (Parameterized Queries)

Defense Option 2: Stored Procedures

Defense Option 3: Escaping All User Supplied Input

From: http://www.owasp.org/index.php/Reviewing_Code_for_SQL_Injection

Best Practices when Dealing with Databases

Use Database stored procedures, but even stored procedures can be vulnerable. Use parameterized queries instead of dynamic SQL statements. Data validate all external input: Ensure that all SQL statements recognize user inputs as variables, and that statements are precompiled before the actual inputs are substituted for the variables in Java.

Daniel here are some books I've read that you may want to take a look at:

"Writing Secure Code". 2nd Edition. M. Howard and D. LeBlanc. Microsoft. 2003.

"The Database Hacker's Handbook: Defending Database Servers". David Litchfield, Chris Anley, John Heasman and Bill Grindlay. Wiley. 2005-07-14.

"The Oracle Hacker's Handbook: Hacking and Defending Oracle". David Litchfield. Wiley. 2007-01-30.

Gray Hat Hacking, Second Edition: The Ethical Hacker's Handbook by Shon Harris, Allen Harper, Chris Eagle, and Jonathan Ness (Dec 20, 2007)

Chained Exploits: Advanced Hacking Attacks from Start to Finish by Andrew Whitaker, Keatron Evans, and Jack B. Voth (Mar 9, 2009)

The CISSP Prep Guide: Mastering the Ten Domains of Computer Security by Ronald L. Krutz and Russell Dean Vines (Sep 10, 2001)

Hacking: The Art of Exploitation, 2nd Edition by Jon Erickson (Jan 11, 2008)

There are many others but these will help you get started.

Over the past 5 years, I've seen a lot of SQL injection vulnerabilities, and properly constructed stored procedures accessed through parameterised queries always fix it. Hopefully we have alleviated your belief that "there is no bigger attach vector than with a parameterized sp"

Rules to stop bad guys

RockyH — Wed, 16 Dec 2009 09:50:14 GMT

I just posted an article to our team blog about simple development rules to stop the bad guys. Head over and have a read. You can find the post on the ACE Team blog.

I know it’s a repost, but sometimes it beats re-writing. ;-)

Bitlocker Broken/Cracked… NOT!

RockyH — Sat, 12 Dec 2009 11:06:35 GMT

Ok, I’ve been trying to keep my cool on this whole thing but enough is enough. A few days ago ars technica ran a hype-story called “First commercial tool to crack BitLocker arrives” (no, I’m not going to link to it because they don’t deserve the traffic IMHO) The claim is that Passware has created a commercial tool that cracks BitLocker encryption. This is misleading garbage. Sorry, there is no other way to put it well there is, but I edited that one out. First, the encryption hasn’t been cracked, second it still requires access to a live machine (sleep is still live).

What Passware actually does, is take an image of the RAM / Swap file and hunt for the decryption key in it. This is nothing new, and nothing that can’t be done with any full volume encryption system, yes including PGP and TrueCrypt. It’s the same thing as the frozen RAM trick and every other Administrator enabled Direct Memory access trick. Passware requires administrative access to a machine that is in a ‘non-off’ state in order to get a snap-shot of the memory and then troll through it to find the key. If your machine is turned off, non of these so-called encryption cracking techniques work, NONE of them.

ALL full volume encyrption systems must have the decryption key available in memory. And no you cannot protect it completely like some people claim PGP does, PGP is just as susceptible, if not more so, to this kind of thing commercial tools like McAfee Endpoint Encryption (formerly Safeboot) and BitLocker.

Now pay attention, Neither BitLocker nor any other drive encryption system is designed to protect data on a drive when the machine is booted, and someone with administrator privileges has access to the machine. People keep conveniently glossing over this fact. BitLocker is designed to prevent off-line attacks such as the ‘stolen/lost laptop’ scenario. If you login to your computer, then hand it to someone, nothing in the world will protect your data.

All of this sensationalist drivel would like you to believe that if you can get at the data which is protected by a disc encryption system from a logged in machine as an administrator that there is some huge security vulnerability. There isn’t. If you have that kind of access to the machine why not just turn off the encryption and save yourself the trouble.

If you don’t have the key in memory when a decryption operation is required, the decryption does not happen. Simple as that. Finding this key in a snap-shot of the computer memory is not rocket science nor is it cracking anything. It is using that key to decrypt the drive. Cracking would be breaking the encryption without the key, which is still not possible in any reasonable amount of time on modern computers.

Now, if someone can do this on a BitLockered machine, that is turned off (not sleep, but cold off) and configured for TPM+PIN+USB key (the recommended secure configuration), then I’ll be impressed. Oh one other thing, you have to be able to get to the data in my lifetime, brute forcing the encryption after about 40 Billion years doesn’t count.

If I locked a door, then hid the key under the mat and told you where the key was, is the door or lock cracked because you were able to unlock it and open the door? No, of course not. This kind of crap about saying BitLocker is cracked because someone had access to the key is garbage. It’s like saying notepad is broken because it saves files in plain text. Then again now that I’ve said that, some of these sensationalists are probably going to start writing headlines like Notepad File Format Cracked!

Ok all of you wanna-be journalists out there (you know who you are), start doing a bit of homework before you drivel onto your keyboard. Try being responsible for just a tiny little bit instead of wondering how many hits you can get on your page by spouting some sensationalist garbage.

Funny, but after being called to task on their sensationalist crap, the ‘writer’ (doesn’t deserve to be called a journalist) updated the post to say “this isn't exactly a "crack" for BitLocker” and “If a forensics analyst or thief has physical access to a running system, it is possible to take advantage of the fact that the contents are in the computer's memory. Other drive encryption programs have similar issues.”

Gee, you probably should have thought that out before you published the drivel.

There are a lot of journalists I respect out there and no they are not all pro-Microsoft. But they do their homework and they write thoughtful, insightful, and factual articles. Be a journalist, not a sensationalist.

Trusting Web 2.0 – NOT!

RockyH — Thu, 03 Dec 2009 23:54:27 GMT

Yesterday, I did a presentation at a customer site for their lunch time security talks. It was about Web 2.0 and protecting yourself online. One of the things I mentioned in my talk was how much people are trusting, blindly, what they see on the social internet.

For example, most of you reading this probably are the ones that set up your ADSL modem/router. Some of you just went and grabbed on from your local computer store, others probably did some research first. Chances are some or all of that research was done on Whirlpool. But who is on there? A couple retailers, manufacturers, and a bunch of hobbyists. Can you trust any of them to provide not only an educated well researched opinion, but an objective one? Maybe 1 in 20.

The most recent Black Screen of Death story that ran like wildfire through the internet this week (after going largely un-noticed last week when Prevx was trying to get into sensationalist journalism to drive traffic to their web site). Prevx stated in this post that this could affect “millions on Windows 7, Vista and XP”, and that it was due to a patch released by Microsoft. Neither of which was remotely true.

Funnily enough, they were offering a free tool to fix the problem, that they were the only ones reporting at the time. coincidence? But I digress for the moment.

When I heard about this, I tweeted that I thought it sounded like malware or a virus. As it turns out, malware does appear to be the likely culprit. It was not linked to Microsoft’s patch, nor did it affect millions of anything. It was an irresponsible knee-jerk reaction to something that really should have been thoroughly investigated before being published on the wild-fire internet. Security and reactions to it are serious across the IT Industry, but it appears that Prevx didn’t think that applied to them.

So as far I my personal opinion goes, Prevx just became a non-entity. I can not trust anything they do from this point forward because they have proven to me that they do not actually check any facts before irresponsibly publishing things. Normally I give people more than one chance, but not where security or public safety is concerned.

What’s more, this “security” company was either:

A) infected with a virus and didn’t know or didn’t bother to investigate

B) Created it so they could flog their free tool to drive traffic to their site

Best case scenario they didn’t know they were infected and didn’t investigate before spouting off. Worst case scenario is B. I don’t know which and this is only my opinion but it bears thinking about.

Prevx has since apologised now that they took time to do their due diligence.

This is a huge problem in Web 2.0. Everyone thinks they are a professional journalist. They use hearsay and conjecture to make claims, usually of an inflammatory nature, just to see how many hits they can get, or to lash out.

In the days of traditional media journalism, the journalists had and understood a responsibility to find and report the truth. Then along came the National Enquirer, and then The Blog, and we started into this death spiral for truth in journalism.

The anonymity of the internet makes people say things they would never say in a forum where they would be held responsible for their actions. Everyone thinks they are entitled to spout nonsense about whatever topic they think is hot at the moment.

Hey, I’m all for personal expression, but don’t try to pass off your opinions as facts without doing your homework. I’m sure I’ve done it in the heat of the moment as well, but go back on the facts. I am certainly going to be holding my opinions until I’ve done my homework now. Research your viewpoint, provide references and facts. At the very least, it will gain you respect and people will think of you as a person that really can be trusted.

If you are on the receiving end, do your own homework. Don’t base your decisions on a couple of forum posts and a tweet or two. Be your own best advocate.

You can’t hide from Shodan

RockyH — Tue, 01 Dec 2009 13:21:09 GMT

I was looking for cool security stuff on the Internet as I do, and I came across this story The Futility of Security By Obscurity on Dark Reading that pointed me to this online search engine called Shodan created by John Matherly.

Shodan is an online search engine for computers. Not news, tweets, blogs, and lolcats, but machines. You can search for machines on the internet that have certain criteria, for example, Using the following query:

I got this sample of the machines in Australia that use ASP.NET:

I could have searched for all machines that returned an HTML response code of 403 (forbidden) or 200 (OK) as well:

In fact you can search on any of these criteria.

Let's say, hypothetically speaking of course, that a bad guy wanted to cause a little DOS annoyances to Apache servers. They could search for systems in Russia running Apache prior to 2.2.14 with a query like: apache 2.2.11 country:RU and get the following results: (sample)

So what does this mean? Well for starters, now Script Kiddies can find all the likely targets they want. Machines that you have set up to handle your personal home network serving your MP3 collection out to you at your office are not safe just because you didn’t tell anyone they were there. Sure people have done port and IP scans for decades, but firewalls and disabling ICMP made your machine vanish from those prying eyes.

While poking around, I even stumbled upon someone's Secure Computing SG management Console for their Secure Computing SG300 router.

(in case you are curious, no, they had not changed the default Admin password…I heard that anyway.)

Now, does this search engine offer anything that could not have been found out with IP scans, trace routes and a bit of caffeine? No, probably not, but this sure puts a nice GUI front end on it and takes the guesswork out of banner grabbing and other skulduggery.

At the moment, it is primarily focused on web server hunting, but John Matherly who created Shodan, is going to be expanding it to FTP, Telnet and SSH. Drop him a line on the site, he's taking suggestions for priorities.

And one more cool tidbit, It uses OpenSearch, which means you can add it to the list of search engines providers usable from the search bar in IE. :-)

Happy Searching!

Security Features vs Security Bugs

RockyH — Tue, 21 Jul 2009 16:04:04 GMT

Several times when I've been talking with customers about implementing an SDL, or what they should be doing to secure their in-house developed applications, I get asked a similar branch of questions.

· Why do we need to review the design if we review the code?

· Why do we need to scan the code, if we are going to penetration test?

· But we are using an authentication library, and we are using PKI, so why do we need to do a security review?

A lot of this comes down to the difference between security features, and security bugs. This is an important distinction and hopefully this article will lend some clarity to why we do all the things we do in an SDL.

Security Features

Security Features are normally driven by regulation, policy, or best practice. Security Features are components you build into your system to handle certain aspects in order to control access to the system. An example of a security features is an authentication / authorisation system. You may be using Active Directory, Open LDAP, or some other kind of system to prove a users identity, and verify that they are allowed to access the things they are requesting access to. Implementing certificate based digital signatures, or using a centralised input validation system are other examples of security features.

Some of the things that identify security features for your application are architecture and design decisions, your choice of libraries or third party components to use, and taking advantage of platform features to provide secure access to your system.

Security features are normally tested by a test team during user acceptance testing. They determine if indeed access to certain assets is restricted to only authorised users, and inversely, that authorised users can get to everything they need to.

Some of the tools used to test security features are your regular testing suites and automated test tools. Test Director comes to mind as one of these. Or even the performance, or load tests build into Visual Studio Team Test.

Most people think that these things are what we mean by creating secure software and in fact this is a large part of it, but there is more to it. Consider this; did you implement your security features, securely?

Security Bugs

Security bugs come from implementing things incorrectly. They are most commonly thought of as vulnerabilities. They can be created in any component of the system and will be there regardless of the security components you build into your system. In actual fact, the security components you build can have security bugs. These are the things that attacker take advantage of to exploit systems.

Some of the things that identify a security bug are validation failures, cross site scripting vulnerabilities, unexpected input that allows your authorisation components to be bypassed. They are normally created by mistakes during development. They are in a word, bugs.

You test for security bugs with fuzz testing, penetration testing, and automated vulnerability scanners. This is where you are not testing for the presence of an authentication mechanism, but how can you break or bypass it. Attackers look for these kinds of problems.

The kinds of tools you use to look for these problems are static code analysis tools such as FX Cop, CAT.NET, and other commercially available tools such as Fortify 360. These are the kinds of problems that penetration tester look for and exploit with other tools like Nessus, Metasploit, and CANVAS.

Now a combination of the two, say failure to implement an input validation system, can compromise your perfectly implemented authentication / authorisation system. These implementation level bugs are more insidious because they are harder to detect, and easy to overlook, especially if project timeframes are short.

Don't confuse security features such as secure firewalled networks, AD integration, and Enterprise Library input validation, with security bugs which can occur in any of these. It is this distinction that drives the multi-level security review and testing approach.

Here is a table that will help define things:

	Security Feature	Security Bug
Example	AD Integration, Enterprise Library Validation Block, Enterprise Library Logging, Input validation components, Firewalls, IPSec	SQL Injection, Cross Site Scripting, Cross Site Request Forgery, Buffer Overflows
Identified During	Architecture Review, Design Review, Threat Modeling,	Code Review, Code Scanning, Penetration Testing
How to test for	User testing, Unit Testing	Pen Testing, Fuzz Testing
Category	Component, Sub System, Dependencies, Library, API	Vulnerability, Mistake, Bug, Accident
Problem Prevention	Best Practice, Standards, Policies	Training, paying attention to detail

The next time a security guy asks you if you have put your developers through secure app dev training, or if you are using an SDL, and code scanning, he’s not referring to you using AD integration and if you have good data access control. He’s asking if you implemented them correctly.

So remember, make sure you do the right thing, and do the thing right.

Finally, answers on the Web – Bing

RockyH — Thu, 11 Jun 2009 11:17:28 GMT

Bing and the world Bing’s with you, Search and you Google alone…

I must admit I wasn’t a real huge fan of the search results that I got with Live. But I think someone was listening.

We introduced Bing to the world and I have to tell ya, it’s all it’s cracked up to be and more. I love the instant answers part of it. Not just for search but for things like flight schedules and even math equations if you are so inclined.

Bing is so much more than a search engine. It’s an Answer Engine. For example here is some of the stuff you can do with the Instant Answers features:

Find instant answers

Need a quick answer instead of a hundred links to websites that might contain your answer? Use our Instant Answers to get what you need fast.

Instant answers are available in the following categories:

Conversions

Convert units of measurements for distance, weight, time, volume, and temperature. You can also include mathematical expressions in some conversion questions to get a calculated, converted answer.

To see the conversion answer in action, try some of these examples:

How many seconds in a day
What is 50 degrees F in Celsius
How many kilometers in a light year

Flight Deals

Get quick access to flight deals and cheap tickets.

To see the flight deals answer in action, try some of these examples:

Deals on specific routes: flights from Seattle to Boston
Deals from a specific city: flights from San Diego
Deals to a specific city: flights to Boston

Flight Status

Make sure you're not late to the airport using the flight status answer.

To see the flight status answer in action, try some of these examples:

flight status for United
flight status
ua820

Hotels

Find a great place to stay wherever you're going with the hotels answer.

To see the hotels answer in action, try some of these examples:

Vegas hotels
hotels in Orlando
San Francisco hotels

Math

Find basic mathematical operators, exponents, roots, factorials, modulo, percentages, logarithms, trigonometry functions, and mathematical constants. In the search box, type the equation that you want to solve or the constant that you want to find the value of.

The following examples show some of the calculations and conversions that you can type in the search box.

Calculations: Get answers to arithmetic problems. For example:
- 5+3/1-(6*2)
- sqrt 9
- sin 100 * 50
- 32% of 54
Equation solver: Solve simple algebraic equations. For example:
- 4x=19
- 2y^2 + 5y + 10 = 40
- Solve 2x + 7 = 4

Note

For more mathematical symbols that you can use in expressions and equations, see Mathematical notations for use with Math Answers

Financial quotes

Go to http://www.bing.com/.
In the search box, type ticker symbols (Letters and numbers that are used to represent companies in stock markets.) for up to nine companies, funds, or indexes, followed by stock or quote.
Click the search button or press ENTER.

Statistical information

Go to http://www.bing.com/.
In the search box, type what you want to find. For example, population of China, or cars in US.
Click the search button or press ENTER.

So of course now I’m off to investigate just how much information can be found out on a person or company through this very powerful Answer Engine. Stay Tuned.

The Storm is Rising

RockyH — Tue, 03 Feb 2009 04:58:00 GMT

Catchy title huh? But what do I mean by that. Hackers take advantage of this kind of chaos, are you ready?

You know when your grandma told you to save your pennies for a rainy day, well the rain is here…a lot of it. In case you hadn’t noticed, a large portion of the civilised world is in the deepest recession in 60 years. This kind of mass economic meltdown is serious business for anyone in the IT Industry. Especially if you are responsible for security. There are three big and common issues that will sneak up on you during times like this.

Data Loss
Poor merging of access control systems
Malicious insiders

Data Loss

Here is why this is such an issue right now. First, one of the things that happens a lot in these kinds of situations is that companies vanish, especially small to medium ones. They are either shut down over night, or they are subsumed by a larger company that was smart enough to save money for a rainy day.

In the fist instance, those companies have lots of proprietary data that has to go somewhere. So let’s give them the benefit of the doubt and say that they didn’t owe anyone anything so they aren’t being liquidated. What happens to the drives their data is on? The most commons ones I’ve seen are:

The hardware is auctioned off
It’s given to employees as parting gifts
Or it’s destroyed

So what if they are lower on the capability maturity model scale and don’t have well established IT policies regarding data destruction? What happens to your data that was stored on those drives? I have seen countless accounts of people buying laptops off of eBay, or at liquidation auctions. When the buyer got them home, they booted up their shiny new toy and it was just like the last guy left it complete with corporate data.

Do you think the buyer is going to report that to authorities so that all the affected people can be notified? NO. his new toy would get confiscated.

Maybe you should start protecting that sensitive data now…just in case. Use Bitlocker. It’s easy, fairly painless and fixes this problem. Maybe you shouldn’t carry around so much old email and old client data on your laptop. If you don’t need it for your current work, keep it on your share at the office. If you really don't’ need it, delete it!

Maintain good data retention policies, and keep that stuff from falling into the wrong hands because you didn’t have time to wipe the drive before the company folded. Sad thought, but very realistic given the current situation.

Poor Merging of Access Control Systems

So what about the other case? The case where instead of just closing, a company is purchased by a larger one? This situation faces a different set of problems.

When you merge two companies, well when one eats the other, you have to combine networks, user authentication systems, and line of business systems. All of these things have to be mashed together to get to one stable system that everyone uses. This can be pure chaos.

Think of all the little things that complicate this as well. Not everyone gets to keep their jobs during these things. So who is responsible for restricting the accounts of people that didn’t make the move? The old company, the new company? During all the chaos of merging, did anyone remember to not include their accounts in the import? Did their data shares get deleted, imported, or abandoned?

How about all of the various CRM systems? Which customer base do we start with? Can we do a smooth import, if we can do one at all? Did we get all of the customers and if we did, are we sure we didn’t overwrite good current information with outdated information?

This kind of chaotic environment provides a ripe hunting ground for hackers. They know that authentication and authorisation systems are being merged and will likely be fairly loose with lots of spare Admin rights floating around until things settle down.

The know that line of business applications are being merged, loaded, deployed, dropped and security reviews are the last thing on the IT Departments mind when everyone is struggling to maintain a plausible bottom line.

What normally happens is that the LOB applications from the child company get dropped onto existing hardware from the new parent company. This causes things to break so configuration on the box is changed until the thing starts working. ‘Just until we sort it out’ of course.

This weakens the security of the existing applications as well as the new temporary squatter applications. So here we open another hole for bad guys to start poking things into.

Malicious Insiders

Then there is my favourite bad issue. The Malicious Insider. I’m sure by now we all know someone who got laid off. I would imagine we all also know someone who probably wasn’t happy about it. What kind of damage do you think they can do before they make it out the door? How many employees had too many privileges? Like the ones that never got revoked after they took on a new position, or when they were given Admin rights for the duration of a long dead project so they could get things done…that were never revoked?

Hey, I know for a fact that the badge I had as a contractor for a place I worked at about 5 years ago, still works and I can still get into the buildings with the door pass. And it’s not a trivial organisation either.

With all of the chaos in these times, the criminal, and malicious elements will flourish. They will take advantage of chaotic merged authentication / authorisation environments. They may even be able to do it with a laptop they picked up on eBay that still had the VPN intact. Or perhaps they used to work for the company and after a layoff they want revenge.

All of the line of business applications that got squashed onto existing hardware are fighting for resources, and have recently changed host configurations. They are ripe for the picking.

In times like these, when you think that you can least afford to think about security, with all the other crap hitting the fan, is the time when you need to think about it the most. Sun Tzu instructed us to take advantage of chaos in your enemy’s camp, and you can bet the bad guys are doing just that. Don’t get caught out because you were distracted. Keep someone on watch in the security space!

IT Departments are flooded with work trying to keep things going while they are loosing staff left and right to budget cuts. They are busy, life is chaotic, and they have too much to do for any of it to be done well. Not to mention the pressure of looking for a new job in case this one vanishes on them.

For the management out there, don't be too hasty to cut back on IT by dropping contractors and staff from your IT budget. If you must, make sure they have a proper hand-over of everything they know or you may find yourself in an untenable situation.

For those of you protecting LOB applications, keep your defences up. If new apps come in that require too many config changes, raise the alarm. Make sure you aren’t leaving yourself wide open because you had to do a bunch of rush deployments. If you do, keep track of all the things you have to go back and shore up in big red letters on the calendar.

Make sure that all of the corporate and legal data handling policies are adhered to. Don’t get sloppy when trying to auction equipment or give stuff to those loyal employees. Remember that the law won’t care if you were having a bad day.

Make sure that when the unenviable situation occurs where people are escorted to the door that their accounts are properly restricted and their badges, VPN, and other access is cancelled. Don’t create an enemy with the keys to your network.

If we all pay attention, we can get through this without too many headlines.

The Vicious cycle

RockyH — Wed, 02 May 2007 15:20:00 GMT

In the IT Security area there seems to be this lack of belief in the old adage, It Can Happen To Anyone. Normally, before a company will get off their collective butts and do anything about their software security, they have to experience an incident. There are all sorts of cliche's we can put here:

A stitch in time saves nine
Learn from the mistakes of others
ad. nauseum

But I think we can agree that cliche's are by their nature things that people tend to think of as well...cliche and don't do anything about. New Flash, cliche's become cliche's for a reason, they usually hold some tidbit of wisdom that is worth paying attention to.

So what does this have to do with the viscous cycle? There is an inevitable series of things that happen after a company experiences a security breach. They are illustrated in the diagram below:

It all starts with a News Headline. As I've said at many of the talks I've given, what I want is to prevent your company from becoming a headline. A semi-wise person once said, "There's no such thing as bad press." WRONG! That only applies to Actors and Politicians. In the IT Industry it's usually all bad press. once the breach leaks into the public eye through press, or regulatory disclosure (http://www.privacyrights.org ) the company and all of it's potential insecure practices come under the microscope. What usually follows is the tossing away of a good reputation.

When the dirty laundry is aired out, the company suffers one of those intangible losses of reputation. In business, more than most places, your reputation is a deciding factor on your success. So if your reputation is destroyed, the domino effect is that you will suffer losses on the bottom line as well. Why does this happen though? After all a reputation is a pretty flimsy thing in today's "less than honorable society so what's the big deal?

If you lose your reputation, your customers, or potential customers will not trust you. It is this golden facet of the relationship with your customers that is so important in today's fast-paced security conscious world. Sure there are some places that don't have to worry about their customers going elsewhere, say the IRS/ATO/DIR (insert the tax collection agency of your choice here). So they probably don't have to worry about this kind of stuff right? WRONG! What happens to them, that is instead of their customer going elsewhere, they undergo one of those new business terms - Reorganization. Either way, you essentially lose out on either potential business, or your job.

So a lack of trust directly relates to a lack of customers. Now this one is pretty simple. No Customers = No Business. However in our ever law-suit-savvy world, there's a new threat emerging.

A lot of people, especially when backed by regulatory red tape like SOx, HIPPA, and others are turning to their lawyers to help 'fix things' when someone experiences a data breach. This usually takes the form of million dollar lawsuits against the companies who experienced the data breach. Of course, when someone sues a big company and gets some money out of it, that makes the news, and we're back at the begriming of the circle again.

So what do we do about this? Well for a long time now we've been hardening the OS layer and the Network layer against attack. To be honest, it's in pretty good shape now. While malicious hackers are very smart, they are like mode code jockeys, lazy. So they tend to go for the weak point, the application layer. No amount of firewalls, IPSec and good intentions are going to protect a company against sloppy insecure programming practices. The Application Layer is the weak link in the chain.

I always fid it a bit ironic that over 70% of the typical IT Security budget is spent on infrastructure, yet over 75% of attacks happen at the application layer. We're spending our money in the wrong place. Infrastructure solutions will always have a problem when it comes to knowing what is acceptable to an application and what is not. No matter how smart the firewall is, it will never know if a SQL string is acceptable input to the application or not. Only the application will be able to inspect and filter the input with any reliability.

We need to focus our attention where it will actually do some good, at the application layer. Don't get me wrong, firewalls, IPSec, and IDS are very good things to have, but they can't be your only line of defense. But we need to concentrate on getting security at the points it's going to do us the most good. There are a couple things you can do to improve your security posture:

Invest in up-front activities:

Threat Modeling
Design Review

Put your developers through secure coding training
Use Secure Deployment practices
Use host level scanning to ensure your servers are configured to security best practice.

Put an end to the cycle!

MS Anti-Cross Site Scripting Library 1.5 Available

RockyH — Tue, 21 Nov 2006 00:30:00 GMT

Many applications today have several common security problems. SQL Injection, poor authentication and authorization, and Cross Site Scripting (XSS) vulnerabilities. The faster and more conssitently we can address these problems the better the security...(read more)

ACE Threat Modeling Links

RockyH — Fri, 03 Nov 2006 01:34:00 GMT

I've been asked several times where to get the new ACE Threat Analysis and Modeling tool. You can find this and more information about ACE Services here: http://msdn2.microsoft.com/en-us/security/aa570413.aspx

Have a look. We're working on getting V2.1 of the tool released. It will be posted there when it's ready.

Can we get something for nothing?

RockyH — Mon, 11 Sep 2006 06:45:00 GMT

A lot of the time when I'm presenting or discussing implementing a Secure Development Lifecycle (SDL) with clients the same question pops up. 'How much is this going to slow us down?' Well to be honest, you can't insert anything into a Software Development Life Cycle (SDLC) without adding some time or resources. The problem is, we've been looking at this from the wrong angle.

We've been creating software for 30+ years now. To be fair, due to the complexity of software and computers in general, we're barely out of our infancy. When we stared we flew into it with rose coloured glasses thinking that everyone who actually 'does computers' will know how to use things and will only use them for the good of mankind. This is par for what humans are prone to doing.

We learned valuable lessons over the past 30 years though. Computers need to be usable by everyone. Because everyone will use them, there will be an element of them that will use them for nefarious means. So our initial ideas about how to build software were not structured for the environment that computers would eventually be running in.

Now if we had perfect foresight, we would have seen that software needed to protect itself from all manner of ill intentions. But we didn't. We thought everyone would play nice. So when we finally figured out that we needed structured processes to manage medium to large scale software development, those processes were developed with that rosy tint.

Now we realise that baking security into our software from the very beginning of the requirements gathering stages is a critical component of a successful project. No longer can we afford to blindly follow our previous rose tinted processes for developing software. The environment has changed. Our foresight, was short-sighted.

So when people ask, will this slow us down, I say; Yes, and well it should! We need to slow down and consider the security landscape we are developing in, and for. We should have baked Threat Modeling, and Secure Code Review, and Penetration Testing right into our development processes many years ago. Had we done that, then we wouldn't even noticed the extra security precautions that we should be using to develop software. But since we've been skipping that all these years, we can't add it without some impact. We should have slowed down and done these things a long time ago.

We aren't trying to break an existing process by introducing steps to slow it down. We are fixing a process that has been broken for 20+ years since we stared trying to work out formal development methodologies. When you are considering introducing an SDL to your environment, don't think of it as slowing down an existing process, think of it as finally fixing a severely broken one.