Security
Security
I am using identity impersonation in one of my ASP.NET projects, and this error popped up today (back from vacation all of 1 hour--it figures).
Parser Error Message: Could not create Windows user token from the credentials specified in the config file. Error from the operating system 'A required privilege is not held by the client. '
Source Error:
Line 7: <customErrors mode="Off" />
Line 8: <authentication mode="Windows" />
Line 9: <identity impersonate="true"
Line 10: userName="registry:HKLM\SOFTWARE\munge\identity\ASPNET_SETREG,userName"
Line 11: password="registry:HKLM\SOFTWARE\munge\identity\ASPNET_SETREG,password" /> |
This error occured on both the production and development machine. The credentials were stored in the registry using the aspnet_setreg.exe tool, and I knew this app worked when I left. Google turned up all sorts of information on how if you're using the 1.0 Framework, you had to grant the user “Run as part of operating system” permissions, but this wasn't necessary if you were using the 1.1 Framework (I am using 1.1). Since I hadn't set this permission in the past anyway, I had a hard time figuring out why this was necessary now.
The answer turned out to be something simple. This application uses a domain user account to log on to SQL server and for file system access. The user account was created specifically for this application in our AD structure, and the option “password never expires” had not been checked. I found this out by attempting to log on to my dev machine as the user. Once the network admin checked the option, we were good to go.
Take home message: look at the easy stuff before you go changing all sorts of permissions, check the easy stuff.
MSDN Digital Blackbelt Security Webcast Series
Hackers are busier than ever. Do you know how they attack? Is your code ready to stand up against those attacks? If you answered no to either of these questions, join us for the Digital Blackbelt webcast series as Developer Community Champion Joe Stagner discusses security risks, vulnerabilities, and solutions from the software developer's perspective. We will provide real-life examples and security tips and tricks that can help you gain the knowledge and techniques to become an experienced “blackbelt” in writing secure code.
Bonus: Be one of the first 300 to attend six live webcasts in this series (and submit an evaluation) and you will receive an official Microsoft security blackbelt!* And by attending a live webcast in this series and submitting an evaluation, you will qualify to win a Portable Media Center (official rules) pre-loaded with our best security webcasts!
Additional site: www.digitalblackbelt.com
hat tip: MJMurphy_TechNet
Interesting read in today's Wall Street Journal. Most interesting is that consultnts push “change often“ mentalities on clients (as often as once a month), and companies that don't require PW changes are often those in the security industry, such as Fortinet. Bottom line from one consultant was it's better to have a PW someone can remember than to change them all the time and have the user write them on a sticky note.
Security experts have long recommended that computer users choose hard-to-break passwords and change them frequently in order to frustrate hackers. Now, those recommendations are being newly forced on millions of U.S. workers in the name of preventing financial fraud under the Sarbanes-Oxley corporate-reform act.
...
No matter that Sarbanes-Oxley doesn't actually require changing passwords: In the name of those "internal controls," auditors and consultants are prodding companies to require that employees pick tougher passwords, and change them more frequently.
But the zeal for impenetrable computer systems rubs up against the limits of human systems. To cope with repeated changes to multiple passwords, many users adopt strategies that actually thwart security.
...
I'm not a big fan of storing a lot of information in cookies and session variables (and even less so if the information is sensitive), but sometimes for any number of reasons you gotta' stash the info somewhere, and cookies and session variables fit the bill. If you have to do this, make sure the information is encrypted. Cookies are stored as raw text files on the user's PC, which can be opened with Notepad or even searched with any number of tools. Session variables, while stored on the server only for the lifetime of the session (hence are more secure), are not 100% secure.
The important issue with storing data in cookies or session variables is that the encryption must be reversible--that is, you must be able to encrypt the data to protect it, and then decrypt the data to use it, and probably encrypt it again after some modification. And so on.
So if you have to use cookies to persist data, or sessions to carry information, be responsible with the data and encrypt it. Here are a few references and tools I have collected:
Encrypting Cookie Data with ASP.NET (15 Seconds)
If you have never seen the voluminous quantity of cookie data on your machine, try the following. Open Internet Explorer, select Tools and then Internet Options from the menu. From the Internet Options dialog click the Settings button. Then on the Settings dialog click View Files. An Explorer window will display all the cached data your browser has kindly filled your hard drive with. Sort the list alphabetically, then scroll down to the Cs. (C is for "Cookie" :)) On my machine, there are currently 1,850 cookie files.
So, here is some advice - don't store sensitive data about users in cookies. If you must, then you have a responsibility to protect that data through encryption.
Encryption/Decryption with .NET (The Code Project)
The System.Security.Cryptographic namespace within the Microsoft .NET Framework provides a variety of tools to aid in encryption and decryption. The CryptoStream class is used here to demonstrate the encryption and decryption with System.Security.Cryptographic.SymmetricAlgorithm, such as DESCryptoServiceProvider, RC2CryptoServiceProvider, and RijndaelManaged classes.
Building Secure ASP.NET Applications (Microsoft PAG - PDF Download)
One of the sections of the huge (600+ page) document discusses DPAPI, a reversible encryption method that is machine specific. This is a must-read for a bunch of other reasons, and also provides a nice segue for the next entry.
DPAPI Helper Library (Franklins.net)
Carl Franklin saved us from building that horrendous “simple DPAPI library” in the above article, with a very simple assembly you can drop into any project and use right away. Carl also has a blog entry on this helper library: http://weblogs.asp.net/cfranklin/archive/2004/03/18/91746.aspx. Read the above article to fully appreciate this contribution.
NCrypto (SourceForge)
So you need some crypto stuff (easy to use and ready for shipping) and don’t have enough time or interest in learning and writing all that crypto code?
Cryptography in .NET (The Code Project)
The cryptography, before the arrival of .NET, was meant to use the Unmanaged Win32 APIs which was very obscure way to encrypt or decrypt the data. .NET provides a set of classes (and actually a complete namespace) for the subject. Now you have a number of classes using different pre defined algorithms which can help you to secure your data using cryptography. In .NET, there are three types of cryptography defined under the tree of Cryptography namespace. Those are AsymmetricAlgorithm, SymmetricAlgorithm and HashAlgorithm. All these three classes (and also types of cryptography in .NET) are abstract classes. We are going to discuss SymmetricAlgorithm in this article.
Since TechNet Mag has some good articles on security, I'd like to share a recent one from InformIT.com. Once you're done reading this, you'll want to just smack the little script kiddie around, and then smack the lazy admins around who allowed him to pull his hijinks.
The Real THR34T KR3W: The Story of Hacker Connor Hansen
source: http://www.informit.com/articles/article.asp?p=348249
In fall 2002, security expert Seth Fogie stumbled into an IRC botnet run by a group called the THR34T KR3W (Threat Crew). He wrote an article about it for Informit, and about a month later headlines started to appear about the arrest of a hacker group called — drum roll— the THR34T KR3W. One member contacted Seth and told him more about the details of THR34T. Eventually the authorities did catch up to the hacker, and the conversation stopped.
Until now. One of the members of the THR34T KR3W, Connor Hansen, recently contacted us to tell his side of the story—how the group worked, wanted they wanted to do, and how he still can't get his stuff back from the Feds.
This post has been moved to http://blogs.aspadvice.com/rjdudley/archive/2005/03/10/3027.aspx. I apologize for the inconvenience. Please remember to update your bookmarks.
http://www.microsoft.com/security/incident/aspnet.mspx
This page was updated October 7, 2004, to include information about a newly released mitigation option, an HTTP module installer. This module protects all ASP.NET applications on a Web server against canonicalization problems that are currently known to Microsoft as of the publication date. We will continue to update this page as additional guidance and resources become available.
This fix will protect all ASP.NET sites on a server. Downside is, this is an MSI that needs to be run on your server. If you don't have that level of access to your server, check with your host or network admins to ensure this fix has been applied.
If you find you need to create your own HTTP module, here is code to do so:
http://blogs.sagestone.net/drobbins/archive/2004/10/06/388.aspx
In case you're just crawling out from under a rock, a vulnerability in ASP.NET Forms Authentication has been reported: http://www.microsoft.com/security/incident/aspnet.mspx.
This issue has to do with canonicalization of URLs. In brief, this is where two different forms of a file name resolve to the same file. There's a brief example and discussion here: http://support.microsoft.com/?kbid=887459. Fiddling with URLs in this way is an old trick, and script kiddies have automated tools that will try and “URL Walk“ to various directories they are interested in. URL Walking affects IIS as well as Apache servers if not protected properly.
In this instance, the URL www.protectedsite.com/default.aspx is protected by forms authentication. However, www.protectedsite.com\default.aspx and www.protectedsite.com%5Cdefault.asp are not protected. The ASPNET engine is not resolving the incorrect '\' in the URL. In IE, the incorrect '\' is automatically converted to a correct '/', but not in FireFox.
However, the IIS utility URLScan prevents these URLs from evenbeing passed to the ASPNET engine. In the urlscan.ini file, the [DentUrlSequences] section contains a list of characters that will result in the URL being blocked. Part of mine reads:
[DenyUrlSequences]
.. ; Don't allow directory traversals
./ ; Don't allow trailing dot on a directory name
\ ; Don't allow backslashes in URL
If you try either of the vulnerable URLs in either FireFox or IE, yuor are greeted with a 403.2 “Permission Denied“ error. The resulting URLScan log entry reads (IP addresses munged by me, long line may wrap):
[10-06-2004 - 09:47:50] Client at xxx.xxx.xxx.xxx: URL contains sequence '\', which is disallowed. Request will be rejected. Site Instance='1', Raw URL='%5Cdefault.aspx'
If you are running IIS 5 and don't have URLScan installed, do so now. You'll find it at http://www.microsoft.com/windows2000/downloads/recommended/urlscan/default.asp.
From what I understand, IIS 6 includes part of URLScan in it already. Maybe an IIS 6 expert can comment on whether or not the [DenyUrlSequence] is included.
I have tested this on a couple IIS 5.0 machines (both prod and dev), and can confirm this to be true on those machines.
Details Emerge on the First Windows Mobile Virus
source: http://www.informit.com/articles/article.asp?p=337069
WinCE4.Dust is the first known Windows CE virus to run on ARM-based devices running Windows Mobile Pocket PC. It was released to all major antivirus companies on July 16, 2004 by its author, Ratter, of the virus-writing group known as 29a (the hex equivalent of the number 666). This is a live, working proof-of-concept virus that infects all .exe files in the root directory of the Pocket PC device.
We all should be familiar with the fact that concatenating user input directly into SQL statements is an open invitation to an SQL Injection attack. Code such as
MySql = "Select * from Orders where Customer ID='" & txtCustomerId & "'"
should be avoided. If you need some more background information on SQL Injection attacks, I am building a reference at http://dotnetjunkies.com/WebLog/richard.dudley/articles/13706.aspx. This reference will be updated as time goes on--there are a few good references now, and I'll post update notices to the security section of my blog at http://dotnetjunkies.com/WebLog/richard.dudley/category/1396.aspx.
The recommended practice for avoiding SQL Injection attacks is to use parameterized queries or stored procedures (sprocs), where user input is passed as parameters. Since information in parameters is not treated as executable code, any SQL code conatined in the user input is rendered harmless. Or is it? This depends on what you do with that input inside of your sproc.
One of the common functions on a web site is querying a data store. In advanced searches (those with more than a single input), it would be infeasible to create and mainatin an sproc for every combination of search critera. Instead, one practice is to create an sproc that dynamically creates the SELECT statement based on the parameters passed to it. Typically, there is an input parameter for each input on the search form, which is rendered optional by adding "=NULL" after the parameter declaration (e.g., @orderId int=NULL). Then, the sproc uses a series of statements such as
IF @orderId IS NOT NULL
select @sql = @sql + ' AND order_id=' + @orderId
to generate the complete SQL statement. At the end of the sproc, the EXECUTE statement is used to query the database using the dynamically generated SQL statement.
I remember what a revolutionary concept dynamic SQL in an sproc was for me when I was learning to write SQL. It opened up a whole new way of writing SQL code and handling advanced searches on my websites. But did you catch the security problem in the previous SQL statement? I didn't at first, and in fact, I've been making this same security mistake for some time now. It wasn't until I finally listened to Kim Tripp on DotNetRocks that I realized the problem (download the show from http://www.franklins.net/fnetdotnetrocks/dotnetrocks.aspx?showid=75), and fortunately I only have a few sprocs to rewrite and fix this problem.
Look carefully at the statement again. It looks like the parameter is being used in the SQL statement, but in reality, the parameter's value is being concatenated to the SQL statement. The technique demonstrated above is no better than the technque we dismissed in the first paragraph.
After listening to Kim's show, I did some digging around, and found an excellent reference on how to handle dynamic SQL in search queries at http://www.sommarskog.se/dyn-search.html. In this article, Microsoft Sql Server MVP Erland Sommarskog details ways to use dynamic and static SQL to perform searches that have a number of possible combinations of inputs.
As Erland shows us, the correct way to use dynamic SQL in the situation I presented above is to concatenate another parameter into the SQL statement, as so:
IF @orderId IS NOT NULL
select @sql = @sql + ' AND order_id=@xorderId'
We then create a parameter list of these second parameters, as so:
SELECT @paramList = '@xorderId'
To finally execute the query, we execute a system sproc named sp_executesql. As Erland states:
sp_executesql is a system procedure with a very special parameter list. The first parameter is a parameterized SQL statement. The second parameter is a parameter-list declaration, very similar to the parameter list to a stored procedure. And the remaining parameters are simply the parameters in that parameter-list parameter.
Our final statement would end up looking like:
EXECUTE sp_executesql @sql, @paramList, @orderId
And with this technique, our query is safe from malicious user input. This whole process is outlined in detail in Erland's article.
Since writing sprocs as outlined in Erland's article can be tedious, I created a CodeSmith template that will do the work for you. You only need to input the table you wish to query, and CodeSmith will generate a complete sproc for you. You can then edit the sproc down, since it will include every column in the table. You can find the template at http://www.ericjsmith.net/codesmith/forum/default.aspx?f=9&m=4346.
Source: http://www.ecommercetimes.com/story/34842.html
Security experts had been waiting for a couple of weeks for the shoe to fall. On June 11, US-CERT, the government-funded computer-security watchdog at Carnegie Mellon University warned that a flaw in Microsoft Internet Explorer could allow a Web site to dump malicious programs onto Windows computers. The alert was highly unusual because CERT normally avoids public warnings about vulnerabilities until patches to fix them are available.
By Friday, June 25, it became clear why the experts were worried. Reports started flowing from security services that unsuspecting computer users were being hit by a program that could log their keystrokes, grab account information and passwords, and send them back to a computer in Russia. The initial assault was stopped over the weekend by shutting down the Russian site and updating antivirus software to deal with the program, known as either JS.scob.trojan or download.Ject. But the basic vulnerabilities remain, and a second wave of attacks seems likely.
This post has been moved to http://aspadvice.com/blogs/rjdudley/archive/2005/03/17/2568.aspx. Please update your bookmarks. Thanks!