IIS6.0 WebDav Remote Auth Bypass

Published: 2009-05-15
Last Updated: 2009-05-19 03:57:00 UTC
by Daniel Wesemann (Version: 2)
0 comment(s)

Quick update on this: There are now two Microsoft blog posts with details:

The MSRC blog at http://blogs.technet.com/msrc and the SRD blog http://blogs.technet.com/srd (the later has more details).

And don't forget about the new KB article: http://www.microsoft.com/technet/security/advisory/971492.mspx

Quick summary: IIS 5.0, 5.1 and 6.0 are affected. The main risk is that unauthorized access to files is possible if WebDAV is used for access control. Writing files appears to be only possible in very specific non-default configurations. Easiest solution: Don't use WebDav. If you got it enabled, check if you actually need it and turn it off (always good to turn off unecessary components).

--

If you're in the security business long enough, this one will sound extremely familiar:  Apparently, adding certain Unicode characters to an URL makes it possible to bypass authentication in Microsoft IIS6 with WebDav and access or even upload files in folders which are supposed to be password protected.

The description was posted to Full Disclosure earlier, and there's a brief comment/analysis on Thierry Zoller's blog.

Yup, we hate to spring such surprises on you on a Friday evening.  If you have WebDav active and accessible from the Internet on any of your IIS6, it is probably a wise move to hedge and turn WebDav off over the weekend, until more details on this problem become available.

 

Keywords: iis Microsoft
0 comment(s)

Warranty void if seal shredded?

Published: 2009-05-15
Last Updated: 2009-05-15 14:16:14 UTC
by Daniel Wesemann (Version: 2)
5 comment(s)

Fellow ISC handler Patrick Nolan commented earlier on the changes to HIPAA requirements that the recent HITECH act brings to hospitals and health care providers in the U.S. The portion that I want to dive into with a bit more detail is

"Electronic media [must be] cleared, purged, or destroyed consistent with NIST Special Publication 800-88, Guidelines for Media Sanitization such that [sensitive information cannot] be retrieved."

NIST 800-88  is pretty succinct and explicit in its demands on how media and harddisks are to be purged or destroyed. "Purging" refers to making the contents unreadable by "degaussing" the disk or using the "secure erase" command in the drive's firmware. "Destroying" in the words of NIST includes "Disintegration, Pulverization, Melting, and Incineration".

So far, so good. But there's a catch. Let's assume that you have a hard drive which contains sensitive data. It doesn't really matter if you are a bank or a hospital or a cutting-edge research shop: The data on the disk is vital. And the disk just snuffs it one day and refuses to spin. Let's further assume that - not uncommon for servers - the disk is still under warranty, and if you ship it back to your vendor, you'll get it replaced for free.

Now what? According to NIST 800-88, a disk with sensitive content which leaves your organization's control has to be destroyed. I strongly suspect though that shipping a baggie of metal confetti back to your vendor could slightly impair your warranty rights. Shipping the disk as-is, on the other hand, exposes your data to all sorts of nightmares, not the least of which being your vendor getting it back to spin and reselling it on eBay as "used, in working condition".

How do you deal with this problem? Do you shred all the disks that leave your shop, forgoing the warranty? Do you degauss the disks before returning, hoping that the degausser actually does its job and the vendor's check doesn't mind? Did you carefully vet your vendor's media handling and have full traceability for all disks returned? Or do you simply take the plunge and hope that your old disk vanishes in the sea of disks offered for resale?

Please let us know by participating in the poll to the right!

Update 1400 UTC: Here's a summary of the responses we received so far. Thanks for all the comments!

The consensus of the responses we received is that saving the cost for a harddrive replacement is never worth the embarrassement, loss of customer confidence and legal mess to be expected when the drive turns up somewhere down the road with the data still intact.

How this is achieved seems to depend on the "muscle" that a firm can bring into negotiations with the vendor. Readers from larger firms and government entities reported that their contract allows them to destroy drives and still get replacement under warranty.

Smaller entities usually just "take the hit", shred the drive, and chalk the replacement down as cost of doing business.

We also received a few responses of readers who use a degausser, and then ship the drive back for warranty replacement. This seems to be a minority though - from the responses we got, most firms don't bother with degaussing, and go for physical destruction in all cases.

Several readers also pointed out that the whole problem starts one step prior .. you need to first find out which of your devices contain disks (multi-functional printers, anyone?) and make sure that your purging/destruction process chosen actually catches them all.

Some comments indicated that full hard disk encryption has made it possible to ship disks around, no problem, but others said that even with encryption, they would not take the risk.

5 comment(s)

Comments

What's this all about ..?
password reveal .
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure:

<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.

<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
https://thehomestore.com.pk/
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
https://defineprogramming.com/
https://defineprogramming.com/
Enter comment here... a fake TeamViewer page, and that page led to a different type of malware. This week's infection involved a downloaded JavaScript (.js) file that led to Microsoft Installer packages (.msi files) containing other script that used free or open source programs.
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
https://clickercounter.org/
Enter corthrthmment here...

Diary Archives