It’s been a looooooooooooong time! in fact it has been a decade long since I’ve been awarded as MVP.
Life is short, how many 10 years you think you will have in your life ?
Just in case.. the profile got taken down !!
Let’s see, I started …way back from IIS 4 if you recalled and all the way up to 7.5. What’s the latest version now? haha!
Getting old/tired/lazy/blur/etc…. it’s been a pretty good experience in this MVP program at least the first 5 :), the remaining years!! NO comment, it has changed so much until I don’t see much values in it. Two things I appreciated the most - Direct PG interaction & MSDN subscription…. the rest are… you know not much. Of coz, good program lead and peers.
Anyway, it is time to retire from the program.
Yet, still a long way before I can actually retire and enjoy life!
It is patch Tuesday and this month we’ve got 3 bulletins (Severity: Important) related to IIS.
MS10-039: Vulnerabilities in Microsoft SharePoint Could Allow Elevation of Privilege (2028554)
MS10-040: Vulnerability in Internet Information Services Could Allow Remote Code Execution (982666)
MS10-041: Vulnerability in Microsoft .NET Framework Could Allow Tampering (981343)
Update – 30th Dec
MSRC response to the vulnerability claim.
IIS team is working on a patch for this so called inconsistency feature
Well, this was reported on Christmas Eve :) regarding file extension bypass on IIS 5.x/6.x.
Read the vulnerability details here, have yet to test it myself, but after reading the doc, this is not as bad I would expected.
I mean if you have #1 allow upload, #2 allow execution on the upload path, #3 the worker processing hosting the app has high privileges, then with or without this bypass IMHO not much different
Of coz, you may argue that validation is done at upload page, say scanning the file extension, etc. In this case, ya it will ‘slip’ through the validation, yet you can also put in more validations? I mean like scan the content before writing the file? scan for <% ?? scan for filetype, header ? bla bla…. ha! I’m not a coder, but this can be done right?
Anyway, from sysadmin side, what you can do is make sure logging is there, even if something really happen, you can trace the culprit; disable Scripts and Executables web permission on the path; grant write access only to trusted user and etc. If you have anonymous write access, you are waiting to get p@wned sooner or later :)
Lastly the moral of the story is – a good defense in depth is not solely depending on the product itself, i.e no bug, no exploit/etc, you will need to assess your business requirement, budget/etc, have good sense of overall setup, understand best practices, lock down as much as you can say port, service, access levels/etc. Give the user as much pain as you can while not causing any lost of business productivity
Cya and have a happy holiday.
Recently, Microsoft released the December security bulletin, and one of the patches related to IIS. Meant to blog about this earlier but Nazim from IIS team beat me to it Been seeing lot of discussions online and patch management related mailing list. So in short, if you are seeing issue on W2k3 IIS 6 after applying the fix via KB973919, you need to repatch SP2 as described in KB2009746.
Update 17th Dec 2009
More details about the fix @ iis.net
And it’s been confirmed that MS has repackaged the fix, read more here.
More updates 22th Dec 2009
MS Support team released a simple VBS script to check if you have ‘broken’ sp2 IIS box, get it here.
Also if you getting the fix via Windows Update, the logic now doesn’t install the patch if you have a broken sp2 machine.
I’m sure you have seen the below warning message many times with IIS 7+
The server is configured to use pass-through authentication with a built-in account to access the specified physical path. However, IIS Manager cannot verify whether the built-in account has access. Make sure that the application pool identity has Read access to the physical path. If this server is joined to a domain, and the application pool identity is NetworkService or LocalSystem, verify that <domain>\<computer_name>$ has Read access to the physical path. Then test these settings again.
Now, you are getting this message, when you clicked on the ‘Test Connection’ button while you adding new site or virtual directory. I have seen quite many posts regarding this misleading message
First of all, this is not an error but warning message instead, next the warning message is pretty self explained, and no need to be extra alarm about it. Anyway, in short because the default application pool identity is NetworkService account, which is a built-in account + default authentication mode is pass-through, hence IIS can’t verify ‘simulate’ or verify the access when you clicked the button. Hmm…. ha! well that’s exactly what’s written in the warning message haha! if you put in a custom account, IIS will take it and access using the account SID, for built-in account, ‘things’ will kick in at run time. Next, if the resource is readible by user, NetworkService account should have no issue reading the file as well.
Anyway, if you do experience access problem later when you test to access the content path, IIS log file – request status code + sub status code is your best friend, if it is permission related you should be getting 401.3 error. You can also get procmon to help troubleshooting access related errors.
Previously, the x86 version you are able to debug 32bit worker processes running on 32/64bit OSes, with this release – you can now debug a full 64bit worker processes.
Here’s the link at Microsoft download, and addtional note for x64 release
Notes about the x64 release:
- Installing both x68 an x64 releases on the same x64 OS is not supported.
- To debug x86 processes running on x64 OS, use the x86 release
Note – the DebugDiag download at IIS.net has not refreshed yet, also it is still using ver1.1 which was released years ago.
Two days ago, a new vulnerability was found in WebDav for IIS, although few have make a big deal out of it, personally I think the impact is ‘quite’ minimum or at least zero in my environment coz I got no WebDav at all LOL… anyway – here is the security advisory from Microsoft. To know more about the vulnerability, you should read this blog post, beside the same basic info you will find over at Microsoft site, it also got a few diagrams to illustrate about the vulnerability and gives you some background about the attack.
The attack is via old folder traversal bug found in previous exploits, the %c0%af which is the encoded UTF-8 for “/” will pass-through the urlscan filter reason being it is a valid chars even though by default % is blocked by urlscan. Anyway – per the detail. IIS 7 is not affected by this and if I remembered correctly (read it somewhere) WebDav in IIS 7 also doesn’t allow anonymous write request. However if you are on IIS5.0, 5.1 and 6.0 with WebDav enabled + anonymous access + write permission for anonymous user then you are subjected to this exploit. Come to think about it – if you allowed write permissions for anonymous user you are basically waiting to get p@wned!!