Slashdot Mirror
Microsoft Issues Ominous ASP.Net Security Warning
An anonymous reader writes "A security flaw in Microsoft's ASP.NET apparently allows access to password-protected areas just by altering a URL. There's no patch yet, but in the meantime Microsoft is telling ASP.NET developers they can rewrite their applications to prevent exploits. About 2.9 million web sites run on ASP.NET according to Netcraft." Some more links: another Microsoft article, NTBugtraq, K-Otik and Heise.
Oh, yeah. Companies now have to "rewrite their applications to prevent exploits" because of a security flaw in Microsoft's software? Would not it be simpler and easier for Microsoft's customers for Microsoft to fix the flaw? Hey, if I wanted to keep my customers happy, that is the course of action I would suggest. Look, you have 2.9 Million web sites out there that now have to go through and invest a number of hours or work to fix the problem. Let's say the fix is easy and only requires say, three hours to recode and test......that is how many hours of lost productivity to the world's GDP? 8.7 Million hours of lost productivity!
Visit Jonesblog and say hello.
From what I read on it on Bugtraq it appears to be one of the good old directory transversal flaws. E.G. if you don't have access to http://server/directory/file.asp you can simply go to http://server/directory\file.asp to access it. That or else use some unicode equivalent. Isn't it funny how Microsoft's leading edge Trustworthy Computing is still vulnerable to the same old sploits?
and use asp2php as found on Freshmeat.
"Straddling the sword of technology..."
Anyone that's familiar with .Net has probably never used this technique to secure a page on their site.
I believe most people would consider it more secure to set up a virtual folder within your web site and protect the pages within that virtual folder with either Basic or Windows Integrated Authentication.
I've never used the web.config file technique to attempt to secure pages that really needed to be secure, and I doubt many other people have either. If you did without taking any other security steps, well... time to re-think that situation.
This security vulnerability will prove to be a dud; nothing along the lines of the old ::$DATA exploits and what-not.
I'm a big tall mofo.
>Put the burden of fixing the problem on the end-users.
Seriously, isn't this the way OpenSource works, since we are all the end-users?
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
In typical anti-MS slashdotter bullshit, the use of the word "re-write" is used quite liberally. A grand total of four lines of code are required per application so no matter how bog the web site is, only four lines of code (typed once in a single source code file) take care of the problem:
By the way, these 4 lines of code can be made into one line of code... Hardly an application re-write.Microsoft has had so many bugs and security flaws over the years that companies are completely immune to bad press for Microsoft. I wonder how much more of this people will finally take until they switch to MacOSX / Linux. I would highly suggest the MacOSX route ....
Proactive?! This vulnerability came to light a week ago - neither Microsoft nor their precious MVPs said a word about it until they could come up with some workaround code - not even a patch. I can hear it now... "if you upgrade to IIS6, you won't have to worry"... ugh.
Sometimes I have to wonder how it is that Microsoft, with all of their talent and wealth, can have so many problems that people of the calibre that their senior engineers are supposed to be could make. I remember talking to one of my professors about software processes and he was convinced that it's possible to have an "error-free" program, this side of the 2nd coming of God and our programming being outsourced to the angels to do for us. Is it a sign that we have matured as users, or that development has regressed that we now consider holes and bugs to be par for the course?
Click here or a puppy gets stomped!
When installing Exchange 2003, a prerequisite is to install asp.net -- so I'm assuming that OWA for Exchange 2003 uses asp.net.
Can anyone confirm this vulnerability in OWA? If it is a problem, is there anything for an administrator to do? I am not a programmer/developer - the MS links didn't seem to have any helpful preventive info.
A couple lines in Global.asax.
If you don't do any funny things with Global.asax.
Plus testing. Plus deployment.
3 hours
Times all affected sites.
A patch would take less time, surely.
Of course, it's nice to have a workaround when you don't have a patch, anyway.
Using a java application server could take much longer, but it should pay in the end:)
I'm not defending Microsoft, I'm simply saying that the actual fix for the problem isn't what the Slashdot write-up implies ("rewrite their applications"). Adding a few lines in Global.asx is NOT a "rewrite".
Although I agree with you in general, I would have been more specific. You should always be checking your GET/POST vars.
From the article, it looks like it's simply switching a '/' to a '\' or the unicode equivalent in the URL to an asp page. It seems like you (the developer) would never get a chance to doublecheck this url as this would seem like it's parsed by IIS and has nothing to do with your script at all.
Again, I'm NOT a ASP.NET dev. but I do do web programming, and it seems that checking your GET/POST vars wouldn't do it.
Can anyone clarifying this further?
AirSpeak - http://itunes.com/apps/AirSpeak
That's pretty funny, but my favorite is still this one
Common sense is not so common.
Today an issue was discovered with Mozilla Firefox which, in the rare case a .config file was used to manage the security and permissions of a folder on a web server, a specially crafted URL could access the contents of the folder. Users are recommened to apply a small code patch to fix the issue.
about face
Today, yet another huge security hole was found in Microsoft software in which blows open all websites running ASP.NET. Microsoft's response? Re-write your code to fix the problem! Just another example of Microsoft's "blame the victim" mentality, when oh when will the madness end?!! We should all switch to Linux and Mozilla and Apache today because those apps never have bugs.
Tech, life, family, faith: Give me a visit
It's not just asp.NET that's affected by bad programming. We use proper computers on our Intranet, not these silly Windows toys. Doesn't mean we're immune to the effects of sloppiness, though. The other day I found an application written by a subordinate of mine, where you could defeat an authentication check by setting a variable in a query string. You could say it's my fault really, for leaving register_globals on; but I find that 90% of the time it's a PITA having it off -- you might just as well be using something old-fashioned like perl if you're going to do that. When you have to read your variables "by hand" you can be sure what order you do 'em in. Sessions - who needs 'em? Just store a filename in a cookie and put the variables in the file, that's exactly how ASP and PHP do it! (Wonders: does having learned to do something the "hard way" first make you less likely to foul up when you come to do the same kind of thing a slightly easier way?) If you're going to be living in a house, you want housey stuff like electricity and plumbing, otherwise you may as well be living in a bender ..... if I'm going to be using PHP, I want PHP-like stuff otherwise it may as well be perl, but with far too many unnecessary round brackets {I grew up on British BASIC dialects which were similarly unfussy; SIN theta was as good as SIN (theta) but it saved you two whole precious bytes}.
I'll be having a word with him about it when he gets back. I distinctly remember telling him to be careful where certain variables came from. I haven't checked his code too closely yet, because I've had other things to deal with; but if I find $auth=$_SESSION["auth"] commented out, I just might have to kill him.
Je fume. Tu fumes. Nous fûmes!
I think not :)
Well fellas, that's another reason to move away from the MS Goliath. He's been falling TOO often!
>
> going to trust Microsoft to get it right?
> How many vulnerabilities does it take?
Maybe you could help me with this one. I've never figured out how one could make a secure PHP program on a multi-user system. All PHP scripts run using the web server's perms, not the programmer's. Which means all data files must be writable and all SQL passwords must be readable by the web server. Which means other people's PHP scripts on the same server also have permission to write to those files or read those passwords.
[blink] [blink]
What am I missing? As far as I can see, there's zero inter-user security when using PHP. CGI scripts on the other hand get to take advantage of suEXEC which allows them to run under the programmer's perms instead of the web server's. But PHP is left out.
Slashdot monitor for your Mozilla sidebar or Active Desktop.
IIS6 is not vulnerable to this. IIS5 is vulnerable but there are security tools that should be running on IIS5 servers (URLScan and IISLockdown) that will block this attack.
.NET's built-in security checks since those are apparently based on the string path and there is always another way to fake a string (server phishing?). I posted a little piece of code here that shows how I check authentication/authorization at the page/function/control level.
Unfortunately, it appears that many (most? all?) shared hosting providers are not running IISLockdown nor URLScan because all of the hosted sites of mine that I tested were vulnerable (except for the ones hosted on Win2k3). So, for those of us doing the shared hosted thing, we needed a fix.
Defense in depth is always a good practice but ASP.NET's directory security was just so dang easy that many of us used it and didn't do security checks on the individual pages and functions like we should have. I admit I am/was guilty of that about 50% of the time (estimated Frida based on the work I did to correct every ASP.NET site I've ever done). I have code in each page now that checks authentication instead of relying on
Microsoft's suggested workaround is easier because you put the 3 lines of code in 1 place, but after this security scare, I don't think I will ever rely on ASP.NET directory security (nor should I have ever relied on it).
The truth doesn't care what I think.
Whilst the security article says this affects Windows 2003 systems - well, most of the time that's just not true. Windows 2003 has a tool called URLScan built in to the IIS6 system - the does not allow this URL through. In addition, there's a tool called URLScan from Microsoft which has been available for 3 YEARS which stops this in IIS 4.0 and above in it's default configuration. Unfortunately, this hasn't been pushed since the Red Alert stuff in 2002 (which this also prevented).
(posted anonymously, so my karma doesn't suffer EVEN MORE)
d =10461007) which says EXACTLY THE SAME THING...
Does someone have something against me, or something?
Holy @#$*(. TWICE in TWO DAYS a perfectly legitimate comment is modded down..
Consider this:
my comment.. flamebait
this comment (http://it.slashdot.org/comments.pl?sid=124766&ci
+5 interesting
WTF??!
I have news for you: 1 password-protected ASP application out of 3 can be accessed using the username ' or ''='' or ''=' and the empty password (the first and last single quote are part of the username).
Reason: SQL injection.
Supposedly these apps verify the password via a construct equivalent to the following (pseudo-syntax, I don't know enough VB to write real code):
answer = query_execute("SELECT account_id FROM users WHERE username=' "+username+" ' AND password=' "+password+" '");
Yes, they use string concatenation to build the query, rather than using wildcards (bind variables)! Not sure ASP even supports wildcards...
What happens with the magic username above, is that a query such as the following is executed against the database:
SELECT account_id FROM users WHERE username='' or ''='' or ''='' AND password=''
(the part of the query coming from the user-entered data is bold, the rest is what came from the program). This is a query that matches for all rows, so you'll usually get connected using the credentials from the first account in the table (often administrator, he!). Try it out! Go to google, seach for login asp username password and pick one of the sites from "the middle of the stack" (i.e. not from the first few pages returned, because those are mostly either ASP tutorials, or the rare "secure" ASP sites). Saying username and password in another language (Benutzername/Passwort) helps too as you'll get a "fresher" less overfished list ;-)
If the simplistic approach doesn't work, try entering a lone single quote as the username and/or password. You'll often get an error message that shows you part of the query used, and from there you can find how to word your username so that you still get access. For instance, some sites do not use the password in the WHERE clause, but instead return it. In that case, use something such as the following as your username, and zozo as the password:
' union select 0,'zozo' from users where ''='
The query obviously neads some tweaking, as the number of columns, position of password in select clause, and names of table obviously varies among sites. But fortunately, error messages are often verbose enough that with a little bit of trial and error you can figure out a "magic" username that opens the door to the kingdom.
If you are a site administrator whose app is vulnerable: rewriting your app is indeed a solution... preferably in PHP!
Say no to software patents.
I tested the 5 sites I've used this feature on over the last couple of years. Out of those 5 sites, only one proved to be vulnerable. I didn't take the time to find any pattern. None was obvious.
The test took about 10 minutes. Then I applied the work-around from MS, and uploaded that to the server. That took about a minute. Then I tested the site in question, ensured that the hole was closed and the site still functioned correctly. The site isn't too complicated, so that took less than 5 minutes.
So the total impact to me so far was less than the time spent reading the replies to this post on slashdot!
That said, I agree that an open source solution where a patch could be released right away would have been much better.
Funny you say that. I was recently working at a bank that was using PHP for all front end and middleware stuff. The 'bank' code itself (which calculated interest and all that jazz) was Oracle and thousands of stored procedures and triggers, but everything else was in PHP. A large contingent of PHP people left at the same time, however, so I'm not sure they'll stick with PHP long term, but that's a business/resource issue, not a technology issue. PHP can talk SOAP to external systems as well as .net or java, which is mostly what was required for that type of system.
creation science book
Microsoft actively encourages use of backslashes in URL's in their Web publishing software. This is done so that it is more difficult to move a web site to a non-Windows server, and also to break older non-IE browsers by making them fail to correctly parse relative URL names.
If they had written this correctly, IIS would, at a very low level, have checked any URL and translated it to a legal Windows filename. This would mean turning any backslash into some other escape sequence before using it to identify the file in the file system (forward slashes could be left alone). This would have been trivial and in fact most original 3rd-party software for serving web pages from Windows did this. This would have immediately stopped the exploit of putting '\' or %5c into the URL.
IIS certainly checks and cooks the URL in many other ways before producing the filename, so lazyness is not an excuse. It is pretty obvious that they wanted to intentionally allow URL's on the web that were non standard and would not work correctly on Unix servers.
More like, "I have a really fast car, but it slams into a wall once a week or so, killing everyone aboard."
>Put the burden of fixing the problem on the end-users.
Seriously, isn't this the way OpenSource works, since we are all the end-users?
Your comparison is flawed.
In Open Source software, the burden is on the programmers, it's just that any end user has both the right, and are provided with the means, to become a programmer. With Proprietary Software, the burden is quite often put on the end user who is provided with limited or inequitable means to do so.
The only viable choice to ASP.NET is Java (a mix of JSP, Servelets, Beans, Enterprise Beans, JSF and perhaps Struts).
Never mix apples and oranges... except if you are making a cocktail.
Cheers,
Adolfo