WebDAV with SSL on VISTA

A while ago I posted an article about WebDAV and SSL on Windows and in the comments some debate was raised about whether Vista supported SSL for WebDAV or not. I hope this article clarifies the question.

In short, Windows Vista DOES support SSL for WebDAV, at least with SP1 and fully patched through Windows Update as of July 26, 2008.

This is the setup I have tested.

Server:
IIS 6.0 running on Windows Server 2003 R2 Ent. Edition. Service Pack 1. English version. Serving www.example.org on port 80 (HTTP) and on port 443 (HTTPS). Server certificate signed by a Windows enterprise root CA ("Example Root CA"). Sharing through WebDAV the following folder: http(s)://www.example.org/shared-webdav. Anonymous access allowed.

Client:
Windows Vista Ultimate Service Pack 1. English version. Certificate of the root CA ("Example Root CA") imported on the local computer Trusted Root Certification Authorities certificate store (this is important, see note below about a "Select Certificate" dialog box).

Command used to map the webdav folder:

net use * https://www.example.org/shared-webdav

Output from that command: (blank lines removed)

---
C:\Users\admin>net use * https://www.example.org/shared-webdav
Drive Z: is now connected to https://www.example.org/shared-webdav.
The command completed successfully.
C:\Users\admin>net use
New connections will be remembered.
Status Local Remote Network
------------------------------------------------------------------
Z: file://www.example.org@ssl/shared-webdav Web Client Network
The command completed successfully.
C:\Users\admin>type z:\hello1.txt
This is file hello1.txt
C:\Users\admin>
---

The network traces showed all traffic going through SSL, as expected.

If, however, the certificate presented by the web server is not signed by a CA trusted by the client, you are presented with a "Select Certificate" dialog box with an empty list of certificates, with only the option "Cancel" available:



As soon as you click Cancel the command fails with the following error message, which, granted, doesn't give much of a clue as to what the real problem is:

---
C:\Users\admin>net use * https://www.example.org/shared-webdav
System error 1223 has occurred.
The operation was canceled by the user.
C:\Users\admin>
---

I hope this helps.

David.

Investigating File Deletion from Windows File Servers - Part III

This article is the continuation of parts I and II and it concludes this "Investigating File Deletion from Windows File Servers" series.

In Part I I provided a network capture file in pcap format (file_deletion_full_trace.cap) and asked a few questions about the deletion of some files from a Windows file server:

Q1 - How many files were deleted?
Q2 - When?
Q3 - How?
Q4 - Who did it?
Q5 - From where?

In Part II I answered questions Q1 and Q2. In this final article of the series I'll answer the remaining questions: Q3 to Q5.

Q3 - How?

From our previous investigation to answer Q1 we know that the files were deleted using the SMB protocol. OK, but what tool and/or procedure did the attacker use? Here we can only guess, since there are several SMB client applications out there and the attacker could have created and used his own. But we can try and do an educated guess.

By far the more widely spread SMB client applications is Windows' own "explorer.exe" (Windows Explorer), so we could ask ourselves: Is it possible that the attacker used plain old Windows Explorer and deleted the files by selecting them and pressing the "Del" key on the keyboard (or right-click>delete)? The best way to test this hypothesis would be to set up a test lab, follow the procedure just described while capturing the network traffic and then compare the network trace with the capture file being studied. If you do that you will see that the network traces, in terms of SMB messages, are almost identical. That would allow us to conclude that most probably that was the tool and procedure used by the attacker to delete the files: Windows Explorer, select a file, right-click > delete.

In fact, that's exactly how these particular files were deleted. I know because I did it :-).

Q4 - Who did it?

We know the files were deleted through an SMB session (potentially, each file from a different SMB session) from IP address 10.10.10.11. So we could be tempted to answer right away Q4 and Q5 saying that the files were deleted by whoever was sitting at 10.10.10.11 at that point in time. But we can do better.

When an SMB session is established the user accessing the server needs to prove his or her identity unless anonymous access is being used. In order to see who (which Windows user) was the owner of the session that deleted the files we need to find the corresponding session establishment and look at the authentication tokens.

Note: From now on (Q4 and Q5) I will be concentrating on the deletion of the first file only (\\SERVER1\PROJECT1\file4.txt, FID 0x8004). The same procedure could be applied to the other file (\\SERVER1\C$\Shared Folders\Project1\file8.txt, FID 0x8001) to obtain the corresponding answers for Q4 and Q5. I'll give the answers for that second file too, but I won't be showing the procedure again. Instead, I'll leave that as an exercise for the reader.

Let's start by selecting the packet where file ID 0x8004 was marked for deletion and let's check the SMB User ID in it:

C:\>tshark -nn -r file_deletion_full_trace.cap \
  -R "smb.disposition.delete_on_close==1 and smb.fid==0x8004"

1707 903.726800  10.10.10.11 -> 10.10.10.3 
 SMB Trans2 Request, SET_FILE_INFO, FID: 0x8004

C:\>tshark -nn -r file_deletion_full_trace.cap \
  -R "frame.number==1707" -V  find "User ID:"

        User ID: 2049

The User ID (2049) is assigned by the server at session establishment (SMB Session Setup AndX Request/Response, smb.cmd=0x73) so let's look for those packets before frame 1707:

C:\>tshark -nn -r file_deletion_full_trace.cap \
  -R "frame.number==1707 or \
  (frame.number<=1707 and smb.uid==2049 and smb.cmd==0x73)"
 598 10.10.10.3 -> 10.10.10.11  SMB Session Setup AndX Response
 828 10.10.10.3 -> 10.10.10.11  SMB Session Setup AndX Response
1527 10.10.10.3 -> 10.10.10.11  SMB Session Setup AndX Response
1707 10.10.10.11 -> 10.10.10.3   SMB Trans2 Request,
 SET_FILE_INFO, FID: 0x8004

We see that the last time that UID is assigned before frame 1707 is on frame 1527, SMB Session Setup AndX Response. Let's find its corresponding request:

C:\>tshark -nn -r file_deletion_full_trace.cap \
   -R "frame.number==1527" -V  find "Response to:"
        [Response to: 1525]

We see that the request was in frame 1525. Let's check out the authentication part inside that frame:

C:\>tshark -nn -r file_deletion_full_trace.cap \
   -R "frame.number==1525" -V  more
[...]
Ticket
    Tkt-vno: 5
    Realm: SANS.ORG
    Server Name (Service and Instance): cifs/server1.sans.org
        Name-type: Service and Instance (2)
        Name: cifs
        Name: server1.sans.org
    enc-part rc4-hmac
        Encryption type: rc4-hmac (23)
        Kvno: 5
        enc-part: C26F4754CD8AEC79F9A8C095147CC075F6038D85074CC0E3...
[...]

The request contains a Kerberos service ticket for service CIFS (SMB) at server "server1.sans.org". This doesn't identify the user yet, but we are getting closer. What we need to do now is see if we can find the request for this ticket to the Ticket Granting Service (TGS) that must have ocurred before, because that request must have contained the Ticket Granting Ticket (TGT) obtained by the user at logon.

Let us find all previous appearances of this service ticket by looking for the encrypted part (enc-part). Using the GUI (Wireshark) we can easily build a filter that will match the whole "enc-part" contents, but to avoid typing too much in the TUI (Text-based User Interface, Tshark) we'll just look for the first four bytes and hope there is no collision:

C:\>tshark -nn -r file_deletion_full_trace.cap \
   -R "kerberos.ticket.data[0:4]==C2:6F:47:54"
824   10.10.10.3 -> 10.10.10.11  KRB5 TGS-REP
826   10.10.10.11 -> 10.10.10.3   SMB Session Setup AndX Request
1525  10.10.10.11 -> 10.10.10.3   SMB Session Setup AndX Request
2813  10.10.10.11 -> 10.10.10.3   SMB Session Setup AndX Request 

We see that the service ticket used in 3 different SMB session establishments and before that, on frame 824, we see the ticket in a response from the Ticket Granting Service. That's the frame we are interested on right now. Let us see its contents:

C:\>tshark -nn -r file_deletion_full_trace.cap \
   -R "frame.number==824" -V  more
[...]
    Source: 10.10.10.3 (10.10.10.3)
    Destination: 10.10.10.11 (10.10.10.11)
[...]
User Datagram Protocol, Src Port: 88 (88), Dst Port: 1076 (1076)
[...]
Kerberos TGS-REP
    Pvno: 5
    MSG Type: TGS-REP (13)
    Client Realm: SANS.ORG
    Client Name (Principal): david
        Name-type: Principal (1)
        Name: david
    Ticket
        Tkt-vno: 5
        Realm: SANS.ORG
        Server Name (Service and Instance): cifs/server1.sans.org
            Name-type: Service and Instance (2)
            Name: cifs
            Name: server1.sans.org
        enc-part rc4-hmac
            Encryption type: rc4-hmac (23)
            Kvno: 5
            enc-part: C26F4754CD8AEC79F9A8C095147CC075F6038D85074CC0E3...
[...]

We see that the response indicates that the ticket was issued to client principal (user name) "david" of realm "SANS.ORG". That is, user "david" belonging to the Windows domain "sans.org" (david@sans.org).

That answers Q4 for file4.txt: it was "david@sans.org" or someone using his authentication credentials who deleted the file. If you apply the same procedure for file8.txt you will discover that it was deleted using a different identity, namely "user1@sans.org".

Q5 - From where?

We already know the deletions were performed from IP address 10.10.10.11, but can we identify the box that had that IP address at that time, like knowing its computer name or netbios name? The answer is yes, we can.

First, let us find the kerberos request to the TGS corresponding to the response we just saw (frame 824, see above):

C:\>tshark -nn -r file_deletion_full_trace.cap \
   -R "udp.port==88 and udp.port==1076"
823 568.900098  10.10.10.11 -> 10.10.10.3   KRB5 TGS-REQ
824 568.901698   10.10.10.3 -> 10.10.10.11  KRB5 TGS-REP

That request must contain a Ticket Granting Ticket (TGT) of the user:

C:\>tshark -nn -r file_deletion_full_trace.cap \
   -R "frame.number==823" -V more
[...]
Ticket
    Tkt-vno: 5
    Realm: SANS.ORG
    Server Name (Service and Instance): krbtgt/SANS.ORG
        Name-type: Service and Instance (2)
        Name: krbtgt
        Name: SANS.ORG
    enc-part rc4-hmac
        Encryption type: rc4-hmac (23)
        Kvno: 2
        enc-part: 92EF34EF9024B61AAD506AECE425F632D5958EED812718CD...
[...]

That TGT must have been obtained from the Authentication Service (AS) at some point:

C:\>tshark -nn -r file_deletion_full_trace.cap \
   -R "kerberos.ticket.data[0:4]==92:EF:34:EF"
773  10.10.10.3 -> 10.10.10.11  KRB5 AS-REP
774 10.10.10.11 -> 10.10.10.3   KRB5 TGS-REQ
776 10.10.10.11 -> 10.10.10.3   KRB5 TGS-REQ
796 10.10.10.11 -> 10.10.10.3   KRB5 TGS-REQ
823 10.10.10.11 -> 10.10.10.3   KRB5 TGS-REQ

We see it was obtained on frame 773. Let us find the corresponding request:

C:\>tshark -nn -r file_deletion_full_trace.cap -R "frame.number==773" -V more
[...]
    Source: 10.10.10.3 (10.10.10.3)
    Destination: 10.10.10.11 (10.10.10.11)
User Datagram Protocol, Src Port: 88 (88), Dst Port: 1069 (1069)
[...]
C:\>

C:\>tshark -nn -r file_deletion_full_trace.cap \
   -R "udp.port==88 and udp.port==1069"
772 10.10.10.11 -> 10.10.10.3   KRB5 AS-REQ
773  10.10.10.3 -> 10.10.10.11  KRB5 AS-REP

We see that frame 772 containes the kerberos request for the TGT. Let us see what this request contains:

C:\>tshark -nn -r file_deletion_full_trace.cap \
   -R "frame.number==772" -V more
[...]
    Source: 10.10.10.11 (10.10.10.11)
    Destination: 10.10.10.3 (10.10.10.3)
User Datagram Protocol, Src Port: 1069 (1069), Dst Port: 88 (88)
[...]
        Client Name (Enterprise Name): david@sans.org
            Name-type: Enterprise Name (10)
            Name: david@sans.org
        Realm: SANS.ORG
[...]
            HostAddress CLIENTXP1<20>
                Addr-type: NETBIOS (20)
                NetBIOS Name: CLIENTXP1<20> (Server service)

Finally, we see that the request for a TGT contains not only the principal name (david@sans.org), which we already knew, but also the NetBIOS name of the computer from which the request was sent: "CLIENTXP1".

This answers our last question, Q5, for file file4.txt: the file was deleted from the computer CLIENTXP1, which happened to have IP address 10.10.10.11 at that time.

If you care to follow the same procedure for file8.txt you will be able to verify that the hostname from which user1@sans.org authenticated was the same, "CLIENTXP1". Actually, what I did to delete the second file was this: while still logged in as david@sans.org onto clientxp1 I used the "Connect using a different user name" option in Windows Explorer to map the second shared folder and provided the authentication credentials (username and password) of user1@sans.org. Then I proceeded like the first time: I selected the file and pressed Delete.

A final note: I have used the domain name "sans.org" all across the article and you will also find it in the network trace. This doesn't mean than any systems belonging to The SANS Institute (http://www.sans.org/) were actually involved in the test lab I set up nor in the real incidents I based this analysis on. It just happens to be the case that the machines I used in the test lab were two of the virtual machines I use when I teach SECURITY 505: Securing Windows.

All the best,
David

Investigating File Deletion from Windows File Servers - Part II

This article is the continuation of Part I, where I provided a network capture file in pcap format (file_deletion_full_trace.cap) and asked a few questions about the deletion of some files from a Windows file server:

Q1 - How many files were deleted?
Q2 - When?
Q3 - How?
Q4 - Who did it?
Q5 - From where?

First of all, let me thank those of you who submitted responses even though there was no prize. Thank you so much for sharing! Most of you, though, only included straight answers and not so much information about how you obtained them. That's OK, but if you did things differently than I'll be showing, please leave a comment with your method so we all can learn from it! There's usually more than one way to do... about everything!

OK, let's go for it. In this article I'll be addressing questions Q1 and Q2 and I'll leave the rest for a future article.

Q1 - How many files were deleted?

A quick method to find out which files were deleted through SMB is using wireshark's display filter "smb.disposition.delete_on_close==1" either in the GUI or with "tshark", wireshark's command line version. Note that I'll be showing tshark (text) output to make the post as light as possible, but you are welcome to use the same filters in the GUI if you want to follow along.

Again, using that filter:

C:\> tshark -nn -r file_deletion_full_trace.cap \
-R smb.disposition.delete_on_close==1 -t ad

1707 2007-03-23 09:45:55.436826  10.10.10.11 -> 10.10.10.3
 SMB Trans2 Request, SET_FILE_INFO, FID: 0x8004
2694 2007-03-23 09:51:29.713222  10.10.10.11 -> 10.10.10.3
 SMB Trans2 Request, SET_FILE_INFO, FID: 0x8001

We see that two files were marked for deletion. The way file deletion works in SMB is a two step process: first, the file is marked for deletion when closed, then, when the client closes the file the server proceeds to delete it. If we want to see the actual moment of the deletion we can show the "close" commands too:

C:\> tshark -nn -r file_deletion_full_trace.cap \
-t ad -R "smb.disposition.delete_on_close==1 or \
(smb.cmd==0x04 and (smb.fid==0x8004 or smb.fid==0x8001))"

1707 2007-03-23 09:45:55.436826 10.10.10.11 -> 10.10.10.3
 SMB Trans2 Request, SET_FILE_INFO, FID: 0x8004
1709 2007-03-23 09:45:55.444123 10.10.10.11 -> 10.10.10.3
 SMB Close Request, FID: 0x8004
1722 2007-03-23 09:45:58.063573 10.10.10.11 -> 10.10.10.3
 SMB Close Request, FID: 0x8001
2694 2007-03-23 09:51:29.713222 10.10.10.11 -> 10.10.10.3
 SMB Trans2 Request, SET_FILE_INFO, FID: 0x8001
2696 2007-03-23 09:51:29.717148 10.10.10.11 -> 10.10.10.3
 SMB Close Request, FID: 0x8001

Frame 1707 marks file 0x8004 for deletion and frame 1709 closes that file, finally provoking its deletion. The same goes for file 0x8001 on frames 2694 and 2696. Frame 1722 shows another close command for a file also identified as 0x8001, but that corresponds to a different file since file identifiers get reused after the previous file has been closed.

Now we need to map those file identifiers to file names. That's easy since Wireshark can tell us if only we ask for payload decoding (option -V in tshark; output trimmed for clarity):

Frame 1707
[...]
      Tree ID: 2051
          [Path: \\SERVER1\PROJECT1]
          [Mapped in: 1659]
      Process ID: 1440
      User ID: 2049
      Multiplex ID: 5504
  Trans2 Request (0x32)
[...]
      SET_FILE_INFO Parameters
          FID: 0x8004
              [File Name: \file4.txt]
              [Opened in: 1704]
          Level of Interest: Set Disposition Information (1013)
[...]
          .... ...1 = Delete on close: DELETE this file when closed
[...]
Frame 2694
[...]
      Tree ID: 2052
          [Path: \\SERVER1\C$]
          [Mapped in: 1767]
      Process ID: 348
      User ID: 2051
      Multiplex ID: 28674
  Trans2 Request (0x32)
[...]
      SET_FILE_INFO Parameters
          FID: 0x8001
              [File Name: \Shared Folders\Project1\file8.txt]
              [Opened in: 2691]
          Level of Interest: Set Disposition Information (1013)
[...]
          .... ...1 = Delete on close: DELETE this file when closed

Combining the tree paths and the file names we obtain the full network paths of the files being deleted:

FID 0x8004:  \\SERVER1\PROJECT1\file4.txt
FID 0x8001:  \\SERVER1\C$\Shared Folders\Project1\file8.txt

Note that although both files may have lived in the same directory in the server (that was the case in this particular case) they were accessed and deleted through different network shares (\\SERVER1\PROJECT and \\SERVER1\C$).

A question remains, though. How does Wireshark know what file name corresponds to which file identifier (FID) and network share? Hint: it's using the ID fields (Tree ID, Process ID, User ID, Multiplex ID). Yes, but how? Would you be able to verify whether Wireshark is correct by checking those fields yourself using appropriate filters without looking at Wiresharks' automatic decoding shown between square brackets? My recomendation: try it! It's fun and you'll learn a lot about SMB!

OK, Q1 solved. On to Q2.

Q2 - When?

This would seem trivial after having found all the information above. However, I don't think it is so much so. Let me explain why.

It might seem obvious that the files were deleted at the following dates and times:

\\SERVER1\PROJECT1\file4.txt:
2007-03-23 09:45:55.436826  (frame 1707)

\\SERVER1\C$\Shared Folders\Project1\file8.txt:
2007-03-23 09:51:29.713222  (frame 2694)

However, I have two problems with that statement.

For one thing, it can be argued that since these frames only contained the request for the files to be marked for deletion the files were actually deleted a little later, when the files were closed. Actually, it would be a little after that, when the server received the close command and then proceeded to delete them, but how long would that be if we want to be exact?

Let me add an additional piece of information to consider. Right after each deletion, we can see in the trace a message sent by the server to the client notifying that the deletion has been completed (filter "smb.nt.notify.action==2", frames 1711 and 2699). Combining this filter with the previous to show the mark for deletion, the close and the notify commands for each file we obtain this:

C:\>tshark -nn -r file_deletion_full_trace.cap -t ad \
-R "smb.disposition.delete_on_close==1 or (smb.cmd==0x04 and \
(smb.fid==0x8004 or smb.fid==0x8001)) or smb.nt.notify.action==2 \
and not frame.number==1722"

1707 2007-03-23 09:45:55.436826  10.10.10.11 -> 10.10.10.3
 SMB Trans2 Request, SET_FILE_INFO, FID: 0x8004
1709 2007-03-23 09:45:55.444123  10.10.10.11 -> 10.10.10.3
 SMB Close Request, FID: 0x8004
1711 2007-03-23 09:45:55.457336   10.10.10.3 -> 10.10.10.11
SMB NT Trans Response, NT NOTIFY
2694 2007-03-23 09:51:29.713222  10.10.10.11 -> 10.10.10.3
 SMB Trans2 Request, SET_FILE_INFO, FID: 0x8001
2696 2007-03-23 09:51:29.717148  10.10.10.11 -> 10.10.10.3
 SMB Close Request, FID: 0x8001
2699 2007-03-23 09:51:29.718439   10.10.10.3 -> 10.10.10.11
SMB NT Trans Response, NT NOTIFY

Now we can be more precise and say that the files were deleted at some point in the following time intervals:

\\SERVER1\PROJECT1\file4.txt, between
 2007-03-23 09:45:55.444123  (frame 1709), and
 2007-03-23 09:45:55.457336  (frame 1711)

\\SERVER1\C$\Shared Folders\Project1\file8.txt, between:
 2007-03-23 09:51:29.717148  (frame 2696), and
 2007-03-23 09:51:29.718439  (frame 2699)

However, I still have a problem with those timestamps. Let us concentrate on the first frame (1709), for example. It was seen on the network at 09:45:55.444123 on 2007-03-23, right? OK, but 09:45 in Madrid, in New York, or where? Actually, those of you living in a different time zone than me and trying the above commands will already be seeing different timestamps for the same frame numbers! Stating a date and time without stating the time zone is ambiguous.

To make a long story short, pcap files contain timestamps in UTC and wireshark translates them to local time at display time. In wireshark's website you can find more information.

You can see the difference in the time displayed by changing the time zone in your computer. Try this:

C:\>systeminfo | find "Time Zone"
Time Zone: (GMT+01:00) Brussels, Copenhagen, Madrid, Paris

C:\>tshark -n -r file_deletion_full_trace.cap -t ad \
-R frame.number==1709

1709 2007-03-23 09:45:55.444123  10.10.10.11 -> 10.10.10.3
 SMB Close Request, FID: 0x8004

Then, change your time zone to something different (e.g. GMT) and try again:
(tip: you can invoke the Date and Time control panel applet directly with "control timedate.cpl")

C:\>systeminfo | find "Time Zone"
Time Zone: (GMT) Greenwich Mean Time : Dublin, Edinburgh, Lisbon, London

C:\>tshark -n -r file_deletion_full_trace.cap -t ad \
-R frame.number==1709

1709 2007-03-23 08:45:55.444123  10.10.10.11 -> 10.10.10.3
 SMB Close Request, FID: 0x8004

Obviously, the above output is from a Windows system. Unix folks will need to play with the environment variable "TZ".

Finally, bear in mind that the option to "Automatically adjust clock for daylight saving changes" also affects the output, although in this particular case it doesn't because the 23mar07 the time hadn't been yet changed for the summer.

With all this, we can conclude that the files were deleted in the time frames stated above (*around* 09:45:55 and 09:51:29 on 2007-03-23), those times being expressed in the timezone "(GMT+01:00) Brussels, Copenhagen, Madrid, Paris" with daylight saving changes enabled.

Answers to Q3 through Q5 to come in a future article...

Investigating File Deletion from Windows File Servers - Part I

I have found myself in this situation a few times now: some critical files disappear from a file server and I am tasked to find out how it happened.

Sometimes I was able to solve the mistery, but other times I couldn't. The most important factor is the information available for me to investigate. Give me a full network trace of the server's traffic and lots of auditing information in the system's logs and I'll tell you that the chances of success are pretty high. Take away any of these elements and things become much more difficult.

Possible causes for important files 'magically' disappearing from a Windows file server are almost infinite. Just to name a few, it could be a bug in the operating system (I haven't seen this kind of bug in many years, but it's certainly possible), malicious software running in the server (this I've seen much more often), or a malicious system administrator or user error (even more often).

Yet another possibility is that someone with valid authentication credentials (e.g. username and password) accessed the folder containing the files through the network using the normal Windows file sharing protocol (SMB/CIFS) and simply deleted them, intentionally or unintentionally. This is the case that I'll be analyzing in detail in this series of articles.

So, how far could you go into finding out who, when, how, and from where removed the files if all you had was a network trace? And if you didn't have a network trace but you had system logs? Do you want to try?

Let us start with the network trace. Here you can find a network capture file, in pcap format (tcpdump, wireshark, etc.) obtained in a lab environment simulating the deletion of some files from a file server. The lab network was just a single Ethernet segment with two systems: a Windows XP (client) and a Windows Server 2003 (server).

If you want to play around with it, (just for fun and the learning experience, no prizes this time, sorry) you can try to find the answers to the following questions:

Q1 - How many files were deleted?
Q2 - When?
Q3 - How?
Q4 - Who did it?
Q5 - From where?

In the next article in this series I'll be showing how to obtain the answers to these questions from the network capture file provided. So, stay tuned!

WebDAV on Windows: SSL and File Locking

Some time ago I described how WebDAV could be used to securely share files among Windows systems across the Internet. Here I will add a couple of notes about the use of SSL to protect the WebDAV traffic and about the file locking mechanism that WebDAV provides, because there are a few limitations you need to know about if you don't want to spend endless hours trying to make work things that simply can't.

On the server side there is no problem at all; IIS can be configured to require SSL connections with any authentication method desired, from basic up to certificate-based authentication, and all WebDAV methods required for file locking are supportedby IIS. On the client side, however, the following facts need to be taken into account.

First, the WebDAV client included in the Windows operating system has the following limitations:

• It does not support SSL.
• It does not support basic authentication by default (from XP SP2 on). You can set a registry key to enable support for basic authentication, but note that it would be a bad move: with no support for SSL the user name and password would end up being sent in the clear across the network.
• It does not support file locking.

Second, Microsoft Office comes with its own WebDAV client that includes support for file locking (out of the box) and SSL (if you install the appropriate patch: KB892211). Note that both file locking and SSL support will only apply to the applications of MS Office (Word, Excel, etc.). For example, if you try to edit a remote file using notepad.exe over an SSL WebDAV connection you have already established using MS Office you will be able to open the file and edit a local copy but you will not be able to save the changes back to the remote share.

All this means that if you want to use WebDAV over SSL and/or with file locking support with applications other than Microsoft Office you will need a third party WebDAV client. There are several products out there, some free and some commercial. Only make sure the product you choose supports the features you want (SSL, file locking, etc.) because not all products support all features.

David.

Windows Scripting for Security

Windows scripting is a very powerful security (and administration) tool. It strikes me, however, that not many system administrators or security experts realize its potential.

This article tries to illustrate that potential with a sample script I wrote to obtain the list of wireless card drivers installed and their versions, from a local or remote Windows system. The script can be found here. (Note: The script has been renamed to .txt to make it harder to execute it inadvertedly. You'll have to rename it back to .vbs to run it).

In the Unix world it is just common standard knowledge that if you are going to perform a task more than once or twice you may want to write a simple script (e.g. a bash or perl script) to do it for you. This way you will be able to repeat the task effortlessly as many times as it is necessary, in as many systems as needed, and at any time it is required (just schedule the script to run with cron).

In Windows environments, by contrast, I find most people normally use GUI tools, only some people use their command-line equivalents from time to time, and almost no one will even consider the possibility of writing a script to perform a particular task if there is no tool available to do it. They will rather say "it can't be done".

In the old days it was true that we only had .BAT files for scripting and very few managament tools had a command line version so trying to solve a problem by writing a script was probably not the way to go. Today, however, we have Windows Script Host (WSH) included in all modern versions of Windows. WSH provides an interface to almost every object in the system and exposes it to several scripting languages like Visual Basic Script (included in Windows), perl and others. With WSH, scripts can interact very easily with entities as complex as the registry, or Active Directory, or the file system and perform very advanced tasks.

I'll give you an example. You may have heard of the vulnerabilities that were discovered on many wireless card drivers a few months ago. Most vendors, if not all, issued patches for their drivers. Now, let's say you read on a web page the versions of the vulnerable drivers. How can you know which version you have installed on your system(s)?

One way would be going to control panel > system > hardware > device manager > select wireless card > right click > properties > driver > details; then take note of the version number and repeat for each wireless card on the system. However, there are two problems with this approach: one, not all wireless cards configured in the system are shown in Device Manager by default (only those currently connected); and two, it doesn't scale. Or would you repeat this process on 100 systems? And what if those systems were remote?

A different approach would be writing a script to check this information for you. Actually, it was pretty easy to write such script: all the required information (number and type of wireless cards installed on the system, their drivers and their drivers' versions) is in the registry and the registry can be accessed from visual basic scripts through WMI (Windows Management Instrumentation) with a simple call to GetObject().

I will not go into the details of the source code of the script because it would make this post too long and I'm not sure it would be interesting for everyone. Instead, I'll show you an example of usage:

C:\tmp>cscript /nologo WMIGetWirelessDriversVersion.vbs localhost

I use cscript.exe because the default WSH executable to kick in, if I didn't explicity specify cscript.exe, would be wscript.exe, which would show the text messages in popup windows instead of a in a text console, which would be annoying (you can try, though, there is no
harm).

The output should look similar to this:

================
Found wireless card at:
HKLM\SYSTEM\CurrentControlSet\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}\{7C1F7564-C990-420E-A4D6-F54092764DF9}\Connection
Name: Wireless Connection 1

Found corresponding driver data at:
HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}\0011
NetCfgInstanceId: {7C1F7564-C990-420E-A4D6-F54092764DF9}
DriverDesc: Intel(R) PRO/Wireless 2200BG Network Connection
DriverVersion: 9.0.3.9
Service: w29n51
ImagePath: system32\DRIVERS\w29n51.sys
================

Instead of localhost you can specify the name or IP address of a remote system. The only requisites are that your current user must have administrative access to the target system and that RPC communication must be allowed between the systems.

Now suppose you manage a Windows OU (organizational unit), domain or a whole forest and you want all systems under your control checked. Could you schedule it to run automatically and collect the results, all from a central location? Oh, yes! That's what Active Directory, Group Policy and network shares are for (among other things), but that's another story.

David.

<plug>
I will be teaching "SEC505: Securing Windows" at SANS Prague 2007 (Feb. 12-17). If you want to discover how a Windows network can be made really really secure (for those of you chuckling... Yes, it can!) come and join me there!
</plug>

PS: Thanks to Joshua Wright, for an interesting challenge, an to Jason Fossen, for sharing his knowledge (he is the author of "SEC505: Securing Windows") and his scripts.

PS: The code in the script is not optimized in any way and it does not do proper error checking. Please don't flame me for that. Instead, feel free to improve it and send me a copy back ;-).

<stats>
The smiley (image) at the end of this sentence has been included to track statistics about this Blog/post. Believe us, it is not a WMF exploit!
</stats>