<script>alert()</script>
<script>alert()</script>
Troubleshooting Networking and IPSec Issues

 

I had a very strange networking issue last weekend.  After connecting to corpnet via VPN and direct hookup, I was able to ping all remote servers, but was not able to do anything, such as web browsing and remote desktop.  It was not the first time that I faced this issue, and helpdesk told me that IPSec settings may have messed up.

The following set of commands has helped me flush settings related to networking and IPSec, and restored my corpnet connection in both situations.

1. Launch a DOS command prompt
2. netsh int ip reset all
3. netsh winsock reset
4. ipconfig /flushdns
5. nbtstat -RR
6. gpupdate /force

Akin to "Ctrl-Atl-Del" of your networking settings, this series of commands should flush IP interface, DNS, Winsock, NetBIOS and group policy settings. 

Good luck to troubleshooting your networking and IPSec issues.

ASP.NET ValidateRequest does not mitigate XSS completely

As a security guy, I can safely say that there is no magic bullet to mitigate any security problems completely, and cross-site scripting(XSS) bugs are not exceptions.  Since ASP.NET 1.1, ValidateRequest can be configured in web.config to check and reject dangerous inputs, and HttpRequestValidationException is thrown before the input is even processed by your code.  For example, <script> would be caught by ValidateRequest.

During my security reviews, I routinely find that many web applications turn on ValidateRequest (It is on by default), and do not follow XSS mitigation techniques, such as output encoding by HTMLEncode or ACE Anti-XSS library.  They believe that ValidateRequest can fix all XSS problems.

However, there are a couple downsides of relying on ValidateRequest:
1. ValidateRequest may miss some crafty inputs.  Please read MS07-040 for a recent MSRC fix on ValidateRequest.

2. ValidateRequest cannot be turned on in all cases, as characters that trigger XSS may also be needed in valid user scenarios.  For example, AJAX transmits XML blobs between client and server, but ValidateRequest will throw HttpRequestValidationException as it contains "dangerous" characters, such as < and >.  Exchange 2007 OWA cannot run with ValidateRequest turned on. 

In conclusion, ValidateRequest should be turned on if it does not block valid user scenarios.  However, even with ValidateRequest turned on, it MUST not be regarded as a sure-fire way to mitigate XSS.  Please read http://msdn2.microsoft.com/en-us/library/ms998274.aspx for full XSS mitigation.

Posted 19 October 07 02:26 by esiu | 5 Comments   
Filed under ,
Read Office Files as ZIP

It is interesting to me that Office 2007 Metro formats can be broken down as a ZIP file.  To see this in action, you can pick an Office 2007 Metro file, such as XLSX and DOCX, and rename its extension with ZIP.  Then open the renamed file with WINZIP.  You will see that Office 2007 content is laid out neatly in a ZIP.  Check out this sample picture.

Let me illustrate a picture from http://www.devx.com/MicrosoftISV/Article/34934

Is Microsoft Office Isolated Conversion Environment(MOICE) mocha on ice?

MOICE may sound like mocha on ice, but it is really a strong dark espresso shot offered by Office TWC team to jolt up security.  Microsoft Office Isolated Conversion Environment (MOICE) is a new security tool that helps protect Office users from malicious documents. Office team strives to enhance their security, and MOICE is another evidence that they are committed to security. 

MOICE converts Office 2003 documents of supported types to Office 2007 XML formats (Metro) in an isolated environment.  Granted that the same conversion engine is used in the Microsoft Office Compatibility Pack, how does running in an isolated environment enhance security?

Think of wearing pads and helmets while playing American football.  It is the nature of American football that players will get hit hard.  Wearing pads and helmets does not change the nature of American football, but it does lessen the chance of inflicting serious injuries on players

The same principle applies to MOICE.  MOICE does not alter the fact that malicious documents are out there to exploit vulnerable machines.  MOICE is like a pad and a helmet to reduce the chance of Office softwares being being exploited.  Exploitation may still happen, but isolated environment provided by MOICE reduces possible damages inflicted by the malicious documents.

In addition, applying MOICE is as simple as putting on a pad and a helmet.  MOICE can be installed as a recommended update via Microsoft Update, and execution of ASSOC replaces regular rendering with MOICE.  For more information, please visit http://support.microsoft.com/kb/935865.

Last but not least, MOICE is not a replacement of properly patching your machines.  Now, go patch your machines, enjoy a cup of MOICE and most importantly, don't click on suspicious Office documents via emails.

Posted 19 October 07 11:49 by esiu | 2 Comments   
Filed under
True test of a security geek

If you chuckle at this comic strip, congratulations!  You are a security geek.  If you don't chuckle, it is never too late to become one.  Read my blog more, and you will become one.

exploits_of_a_mom

Thanks TechJunkie for forwarding.

Posted 11 October 07 01:18 by esiu | 2 Comments   
Filed under
Given enough eyeballs all bugs are shallow: True or False?

"Given enough eyeballs all bugs are shallow."  I do agree if more right-minded folks look at a piece of code, it would help identify both security and non-security bugs.  This premise is built on the assumption that all reviewers have the best intentions in mind.  However, do all people have the best intentions in mind?  If all do, we will not need law enforcement officials.

Obviously there will be some malicious and devious "eyeballs" out there.  Rather than identifying bugs, they plant bugs in open source softwares.  This attack is named "Cross-Build Injection".  Fortify just published an article with reported incidents related to OpenSSH, SendMail and IRSSI.  Check out http://www.fortifysoftware.com/servlet/downloads/public/fortify_attacking_the_build.pdf.

Posted 11 October 07 12:18 by esiu | 2 Comments   
System.URI.AbsolutePath Vs Phishing Attack

Phishing attack can be caused by users inadvertently clicking on malicious links in emails or web pages, which then forward requests to malicious websites.  A common phishing technique is to fake emails sent by well-known banks or merchants,, which contain malicious hyperlinks.  Successful phishing attacks allow attackers to steal online user identities, install malwares on the users' computers, etc.

A careful user named Clever John checks each link before clicking it.  Some common phishing emails contain links with IP addresses, for example, http://123.123.123.123/notice.aspx.  Obviously, famous banks or merchants are not likely to use IP addresses on their public announcement emails.  Clever John decides not to click on emails that contain those suspicious links. 

What happen if the link is http://www.famousbank.com/notice.aspx?redirect=http%3a%2f%2f123.123.123.123%2fnotice.aspx?  This time Clever John checks the link as usual, and sees that it is originated from http://www.famousbank.com.  In addition, the email graphically looks very convincing.  Little does Clever John know that he just gets attacked by a phisher who exploits a phishing security bug on http://www.famousbank.com, and malwares are installed on his machine quietly, as a result.

Let's analyze the code behind the phising security hole.  Here is sample code that is susceptible to phishing attack:

String redirectsite = request["redirect"];
response.Redirect(redirectsite);

Basically, the code redirects the server response to a location specified by redirect parameter in the request.  This is a common scenario, for example, redirecting to home pages upon logoff in the form of http://www.famousbank.com/logoff.aspx?redirect=home.htm.  Unfortunately, since redirect parameter is not verified, attackers exploit the hole to redirect requests to any sites of their choice.

In order to fix this bug, the redirect parameter MUST be validated.
* If the response should only be redirected to links of the same site, please check for "//".  If "//" is present, it should be deemed as an invalid request.
* If the response can be redirected to external sites, more intelligent filtering must be in place.  Define all the valid sites that can be redirected, and allow to be redirected to only those valid sites. 

Someone asked if System.URI.AbsolutePath can be used to strip hostname and port number as a mitigation.  Then, redirect to the location returned by System.URI.AbsolutePath

Let's analyze what System.URI.AbsolutePath does. 

// link0.AbsolutePath returns "/default.aspx"
Uri link0 = new Uri("http://www.evil.com/default.aspx"); 

// link1.AbsolutePath returns "//www.evil.com/default.aspx"
Uri link1 = new Uri("http://www.evil.com//www.evil.com/default.aspx"); 

You may think "//www.evil.com/default.aspx" is not a valid address because it does not start with "http:".  However, web browsers, such as IE and Fire, would gladly prepend "http:" in front of "//www.evil.com/default.aspx", and redirect to http://www.evil.com/default.aspx.  In other words, AbsolutePath alone is not effective against phishing security hole.

Phishing Attack wins in this heads-on "System.URI.AbsolutePath Vs Phishing Attack" battle .

Posted 10 October 07 08:09 by esiu | 2 Comments   
Filed under
Web Service Security Guidance

I have just published a Technet article.  This is geared for administrators and developers as an introduction to web service security.  It contains lots of references that allow you to deepend your knowledge of web service security.

Please visit http://www.microsoft.com/technet/community/columns/sectip/st1007.mspx.

Your feedback is welcome.

Posted 10 October 07 04:56 by esiu | 3 Comments   
Filed under
More eyeballs for .Net Framework code

Microsoft will open up source code of .Net Framework to the public.  It allows outsiders to review what is under the hood, and enables easier debugging of development projects around .Net Framework.  .Net Framework code has been reviewed heavily, and developers can pick up coding best practices by reviewing source code of .Net Framework.

The following libraries are available:
* Net Base Class Libraries (including System, System.IO, System.Collections, System.Configuration, System.Threading, System.Net, System.Security, System.Runtime, and System.Text).
* ASP.Net (System.Web).
* Windows Forms (System.Windows.Forms).
* ADO.NET (System.Data).
* XML (System.Xml).
* Windows Presentation Foundation (System.Windows)

Source code is made available under the Microsoft Reference License, which is intended for developers to have read-only access.  However, it does not allow modification or distribution.

An additional feature: It supports JIT code download for debugging in the final release of Visual Studio 2008.  If set up properly, you don't need to download all source code on your box.  You can get it when you need it transparently.

You can read this article for more details.

Anti-Malware and Spyware help for home users

Working for Microsoft means that I become de facto technical support for my friends and family.  That should be the experiences of many folks in the computer industry.  When I introduce my job title as "senior security consultant" to friends and family, I get promoted to become technical and security support, and instantly I am bombarded with security questions about viruses and spywares.  They all want to know what good products are out there, and they also want "free" solutions.

Personally, I don't worry about choosing an anti-malware detection and removal tool as all my laptops and desktops have installed malware and spyware detection and removal tools provided by Microsoft IT.  I do want to help out my friends and family.  I discover that, fortunately, free lunch is available from Microsoft to detect and remove malwares and spywares on personal computers.

Free online spyware and malware detection and removal (XP)
* Spyware and malware: Windows Live Onecare Safety Scanner (Run on demand)

Free installed spyware and malware detection and removal (XP)
* Spyware: Windows Defender (Signature updated on Tuesdays and Thursdays via Windows Update)
* Malware: Malicious Software Removal Tool (Signature updated on the second Tue of each month)

Free online spyware and malware detection and removal (Vista)
* Spyware and malware: Windows Live Onecare Safety Scanner (Run on demand)

Free installed spyware and malware detection and removal (Vista)
* Spyware: Windows Defender (Signature updated on Tuesdays and Thursdays via Windows Update.  Comes with Vista already)
* Malware: Malicious Software Removal Tool (Signature updated on the second Tue of each month)

Actionable Steps
1. Set up a reminder to run Windows Live Onecare Safety Scanner regularly

2. Always accept Windows updates when prompted on the system tray icon.  This provides signature updates to spyware and malware detection and removal tools, namely, Windows Defender and Malicious Software Removal Tool.  It also triggers scanning of your machine by Malicious Software Removal Tool.

  

3. Your broadband network providers may provide commerical-grade scanners for free.  For example, Comcast subscribers can use the scanner product from McAfee.  Shaw subscribers in Canada can use a co-branded version of scanner from F-Secure.  Please check with your broadband service providers.

4. Consider Windows Live OneCare (Windows Live Onecare Safety Scanner is a different product).  You get what you pay for.  It is a paid solution that provides both security and performance features, such as malware detection and removal, firewall, backup, and PC tuning.  Its latest version is available for 90-day free trial.  Although subscription price is $49.95 per year, detection and removal of spywares and malwares will always be active.

Posted 26 September 07 12:37 by esiu | 1 Comments   
Filed under
HTTP Header Injection Vulnerabilities

HTTP Response Splitting was discovered several years ago.  It allows attackers to split a HTTP response into multiple ones by injecting malicious response HTTP headers.  This attack can deface web sites, poison cache and trigger cross-site scripting.

Rather than splitting responses, I want to demo how to poison user cookies by using Response.Cookies as an attack vector.

Normally, http://www.mysite.com/test/default.aspx?text=esiu sets the cookie [username] with a value of "esiu".  Let's examine the code below. 

// Query parameter text is not checked before saving in user cookie
NameValueCollection request = Request.QueryString;

// Adding cookies to the response
Response.Cookies["userName"].Value = request["text"];

Unfortunately, a grave security mistake is made because input is not checked properly.  You may think, "Big deal?  A random cookie value can be saved on a user browser.  What is the harm?"

Here come along an evil hacker.  The hacker uses the following URL: http://www.mysite.com/test/default.aspx?text=esiu%0D%0ASet-Cookie%3A%20HackedCookie=Hacked.  Let's dissect this, and see what harm the hacker intends to do.

Set-Cookie header is used in HTTP response to request browser to save a cookie.  %0D%0A is a newline character on a HTTP response encoded by URL encoding, which is usually represented as "\r\n" in code.  In other words, the evil hacker is trying to use the newline character as a line separator to add Set-Cookie header immediately after the original cookie.  As a result, a malicious HackedCookie is added with a value of "Hacked".

Let's examine the HTTP response headers of both benign and evil requests to better illustrate this attack.

You should see the following segment in the HTTP response with the benign request.

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
Date: Thu, 20 Sep 2007 20:11:50 GMT
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Set-Cookie: userName=esiu
Cache-Control: private
Content-Type: text/html; charset=utf-8

Here is the response header with the injected Set-Cookie header.  Note the underlined Set-Cookie header.

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
Date: Thu, 20 Sep 2007 20:11:50 GMT
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Set-Cookie: userName=esiu
Set-Cookie: HackedCookie=Hacked

Cache-Control: private
Content-Type: text/html; charset=utf-8

ASP.NET 2.0 has made this attack almost impossible because by default, "\r\n" is disallowed in methods that involve HTTP response headers.  You need “enableHeaderChecking” set to false in web.config in order to pull off this attack.  Not many valid user scenarios require applications to turn off “enableHeaderChecking”

Here is the response header with "enableHeaderChecking" turned on.  Note that %0D%0A is interpreted literally.

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
Date: Thu, 20 Sep 2007 20:11:50 GMT
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Set-Cookie: userName=esiu%0D%0ASet-Cookie: HackedCookie=Hacked
Cache-Control: private
Content-Type: text/html; charset=utf-8

It is good to be educated, but you should be safe.

Posted 22 September 07 11:36 by esiu | 1 Comments   
Filed under
Reset Outlook connections without restart

This is a well hidden trick in Outlook.   Not sure why this needs to be hidden.  You can open Connection Status window by holding CTRL + right-clicking on the Outlook system tray icon on the Task Bar. 

I want to highlight a couple features:

* Reset all connections by clicking on Reconnect.  It helps resolve some problems
* Diagnose some Outlook problems by checking Req/Fail, Status and Conn columns. 

I am using RPC over HTTPS to connect to my Exchange server, and most connections are good (Established).  Despite Established, there are a few intermittent connection failures shown on Req/Fail, which warrant some investigation.

This hidden tool should become your friend as you troubleshoot Outlook.

Posted 22 September 07 11:21 by esiu | 1 Comments   
Filed under
Silverlight security MSDN magazine article

I have submitted an article proposal to MSDN to write about Silverlight security with my buddy in Silverlight team.  If this proposal gets accepted, you will see the article on MSDN magazine soon. 

Abstract:

Silverlight is the latest cross-browser and cross-platform web application development technology offered by Microsoft.  It enables authoring of more dynamic and graphic web content rendered consistently on all popular Web browsers, including Microsoft Internet Explorer, Mozilla Firefox, Apple Safari, and Opera, and on Microsoft Windows and Apple Mac OS X.  In order to leverage Silverlight securely, we need to review Silverlight from the perspective of development and deployment.   Similar to other web applications, Silverlight applications are susceptible to web-based attacks, such as cross-site scripting and SQL injection.  Code must be securely written to withstand those attacks.  The functionalities that Silverlight offer can also be misunderstood and used improperly, leading to vulnerabilities both in the server and in the client. In addition, standard deployment security issues apply to Silverlight applications, but the seamless deployment model allows administrators to secure their servers without specialized Silverlight knowledge.

Outline

  1. Introduction
  2. SL Development Environment Introduction
  3. Secure Development Best Practices
  4. Commonly misunderstood programming patterns
  5. Secure Deployment Best Practices
Just learned how to cross-post via MetaWeblog API

I work for ACE team, and want to cross-post from http://blogs.msdn.com/esiu to http://blogs.msdn.com/ace_team.  Community Server supports MetaWeblog API, but I am not able to figure out how to configure cross-posting.  After a few tries, I am able to cross-post now.

Community Server asks for several things

URL: http://blogs.msdn.com/blogs/metablog.ashx.  Don't use http://blogs.msdn.com/<appkey>, and in my case, http://blogs.msdn.com/ace_team.
AppKey: target blogid, in my case, ace_team
Username: target blog login
Password: target blog password
Message to add: A header message on each cross post

Last not but least, you need to enable cross-posting in Global Settings -> Default Post Settings -> Enable Cross-Posting.

Hopefully, this will save you time as I spent numerous research hours figuring this out.  I also apologize for polluting the blog atmosphere by a few phantom test messages while testing various configuration settings.

More Posts Next page »
Page view tracker