Wade Hilmo - All Comments

re: Running Perl on IIS 7

ragrone — Tue, 03 Nov 2009 22:24:28 GMT

okay what am I missing here?

I have these instructions as well:

Executable: C:\Perl\bin\perl.exe "%s" %s

Extension:.cgi

Verbs Limit to: GET,HEAD,POST

Check that file exists: (uncheck this box)

What is this and where does it go?

Microsoft strikes SQL Injection

.net Brainwork — Tue, 27 Oct 2009 17:48:02 GMT

Microsoft strikes SQL Injection

re: Understanding Versions of the IIS FTP Server

Chat — Tue, 15 Sep 2009 00:32:52 GMT

<a href="http://www.liderchat.net" title="Chat, Sohbet" target="_blank">Sohbet</a>

<a href="http://www.mircbul.net" title="mirc, mirc indir" target="_blank">mirc indir</a>

<a href="http://www.ozlusohbet.net" title="Sohbet" target="_blank">Sohbet odalari</a>

<a href="http://www.dostyakasi.com" title="Edebiyat Forum" target="_blank">Edebiyat</a>

re: Understanding Versions of the IIS FTP Server

Rovastar — Thu, 10 Sep 2009 01:58:38 GMT

Thanks that clarifies things more.

Now there are 2 vulns it makes sense with the confusion.

I still think there should be more public information on the advisory for the windows users.

As said before not all ftp accounts are 100% trusted. In a typical hosting environment you will allow clients/customers ftp access to there site. Obviously you will give them FTP write access. And I do not know the hundred or thousands of ftp customers and can vouch for them 100%.

In the real world I cannot imagine many servers willingly having anon access and write access but I can see many cases for write access to auth users. And also these auth users will have create dir access too.

The advisory doesn't mention users write access at all and only mentions anon access. Surely the advisory should mention all types. The admin shouldn't have to dig through blogs to find this information. Not to mention that it implies you will be safe if you disable anon access this plainly is not the case.

You don't help admin evaluate the risk here you misled them. I would read that advisory and think I am not stupid enough to have anon write access therefore it does not apply to me. I have reviewed many advisories before for rollout in large web/hosting environments and tbh I would think that is ok if you do not have anon access enabled/non-write access for it.

re: Understanding Versions of the IIS FTP Server

wadeh — Tue, 08 Sep 2009 05:07:18 GMT

Rovastar,

I believe that Nazim took is blog down temporarily to make some corrections. It was not taken down because it revealed too much. He wanted to make it more accurate. Also, anything that Nazim or I say in our blogs is public information and you may feel free it.

To answer your specific questions:

FTP 5, with both IIS 5.0 and 5.1 (on Windows 2000 and Windows XP respectively), have a known vulnerability that can result in remote code execution in the context of the local system account. The only known way to achieve this requires that the attacker has the ability to create directories on the server machine in a location that is reachable through the FTP server.

FTP 5 and 6 are vulnerable to a denial of service attack if the attacker has read access through the FTP server. This is true of all platforms for these versions (IIS 5.0, 5.1, 6.0 and 7.0, running on Windows 2000, Windows XP, Windows 2003 Server, Vista and Windows 2008 Server.) The first version of the advisory did not list FTP 6 on Vista and Windows 2008 Server as vulnerable to this because the original vulnerability did not affect them. The second vulnerability, which was disclosed to us on Thursday last week, added FTP 6 on Vista and Windows 2008 Server to the matrix.

FTP 7.0 and FTP 7.5 are a completely different code base and are unaffected by any of the known vulnerabilities.

The critical factor is whether the attacker can read through FTP or create directories. It does not matter whether the attacker is logged in as anonymous or with a Windows user account. The reason to call out anonymous versus authenticated is only to help administrators evaluate the risk to their servers.

I hope that this helps to clarify.

-Wade

re: Understanding Versions of the IIS FTP Server

Rovastar — Fri, 04 Sep 2009 09:33:42 GMT

Hi Wade,

Nazim's blog post about this subject got removed where I was having a conversation about the security advisory and these exploits.

(that post contained much useful information about this vuln, where has that gone? Is it because it gave to many details away? Can I repeat the details?)

Still these are not clear to me.

From your post here and Nazims post before and discussion the only versions that are problematic are FTP 5 for Win 2000 where full takeover is possible.

FTP 5.1 for XP & FTP 6 for Win 2003 where a DOS attack is possible as these OS have /GS buffer overflow protection in the OS. And there is no effect for 2008 running FTP 6.00001 (lets call it. come on were is the version numbering. :) ) & 2008 running FTP 7 and 7.5 are unaffected.

Why then does the second revision of this security advisory state that Windows 2008 and vista are affected? In teh summary it says that IIS& is vuln to a DOS attack vector. You and Nazim have both said that is not the case! This is very confusing before in revision one it said 2008 and vista are not affected (only the related knowledge base article said it was but I presumed that was a typo) and this was confirmed by you and Nazim now it says they are?! Why is this? It makes no sense is is more confusing to your customers. Even in the detail it is confusing points 3) and 4) of the FAQ there are different. point 3 says that IIS7 (i.e Vista and 2008) are affected with a DOS and point 4 (and others) says the detail of the DOS is only for Windows 2003.

The advisory also doesn't mention authenticated users and just the anonymous account. It really should mention this. It implies in the workaround that if you remove the anonymous write access you will be safe from what I understand this is not the case (or wasn't as per Nazims blog post that no longer exists)

Please make the advisory clear. Third time lucky. :)

If I am speaking out of line here and want these issue to be discussed privately please let me know.

re: Running Perl on IIS 7

dgallek — Wed, 01 Jul 2009 20:34:53 GMT

re: UrlScan 3.1

rebeccascott — Thu, 18 Jun 2009 14:04:25 GMT

Has it been confirmed if this product works with MCMS?

chimpanzee attack: Filtering for SQL Injection in IIS7 « zycd.net.cn

chimpanzee attack: Filtering for SQL Injection in IIS7 « zycd.net.cn — Thu, 26 Feb 2009 02:14:03 GMT

Pingback from chimpanzee attack: Filtering for SQL Injection in IIS7 « zycd.net.cn

chimpanzee attack: Filtering for SQL Injection in IIS7 « zycd.net.cn

chimpanzee attack: Filtering for SQL Injection in IIS7 « zycd.net.cn — Thu, 26 Feb 2009 02:13:54 GMT

Pingback from chimpanzee attack: Filtering for SQL Injection in IIS7 « zycd.net.cn

re: Filtering for SQL Injection on IIS 7 and later

daniele.baldessari — Mon, 16 Feb 2009 16:35:45 GMT

Is a bug ? After apply the SQLInjection rule settings the querystring lenght is set at max 25 char. It's not possible overriding the setting with <requestlimits />

how can I do ?

Filtering for SQL Injection in IIS7

wsspectacular — Thu, 12 Feb 2009 20:21:15 GMT

One of the most common attacks against websites is a SQL Injection attack. What is a SQL Injection Attack

Filtering for SQL Injection in IIS7

wsspectacular — Thu, 12 Feb 2009 20:21:13 GMT

One of the most common attacks against websites is a SQL Injection attack. What is a SQL Injection Attack

re: How IIS can help with SQL Injection

Anonymous — Wed, 28 Jan 2009 12:57:18 GMT

How to use Adsutil.vbs to set my virtual Directory(my web site) process identity to Local system..Please help me out im struggling from 2 days...

re: UrlScan 3.1

PepperdotNet — Fri, 23 Jan 2009 21:28:01 GMT

Wade,

This looks like a great tool. I spent most of the day yesterday implementing it on one of our Win2003 x86 development servers. It does exactly what it needs to do.

Now, I need to take the next step and put it on our test platform which is Win2003 x64. No matter what I've tried, I cannot get URLScan to do anything. We needed x64 so that additional memory would be available for additional, larger application pools, but the application pools run in 32-bit mode for compatibility with some classic ASP and 32-bit resources it depends on. I think this is at the root of my problem but I have no idea how to work around it. This scenario (32-bit compatibility on x64) needs to be addressed in the documentation.

Can anyone help me with this?