 My name is Matt Shannon. I work for KPMG as part of the Information Risk Management Group. We do penetration testing, vulnerability assessments, general security work. What I'm going to talk about today is Microsoft Front Page. And I'm going to cover a couple of different topic areas. It's a pretty heavily deployed tool that's not very well known. I'm going to cover the protocol, the back end systems. I'm going to cover a simple brute force authentication scanning program I put together. And I'm going to talk about what to do when you gain front page access. I'm going to talk about ASP. I'm going to talk about some of the powerful ASP components and tools you can use to gain further access. And then I'm going to wrap it up with how to secure front page. All of you have friends, relatives, girlfriends, clients, others that insist on running front page. This is how you take the extra steps to prevent the people who have attended this conference from doing anything to them. And just to get us all on the same page, before we begin, we're going to talk about a lot of tools and techniques in here. We all know you've got to use these on machines that you have permission to use them on. So get your written permission ahead of time. Let's get started. Lay in the ground front page. Microsoft front page, what is it? God, you have to ask that question. You've been under a rock for the last ten years. It's Microsoft's integrated website development tool. It's a system for adding basic to advanced functionality with little or no web page experience. In addition, it's an integrated Microsoft Office package, and in my personal opinion, the security nightmare. It was built by Vermeer Technologies in early 1995. Vermeer was one of those dot com explosive firms that created front page to capture the web boom. And following an enormous success that were bought out by Microsoft in 1996, the original programming staff still works for Microsoft, although the management's moved on to new endeavors. As a side, all DLLs, all functions within front page start with the under store VTI under store Vermeer Technologies. Decoding the system. We're going to talk a little bit about the HTTP protocol and what's going on behind the scenes when you access it and administer a front page site. It's client server communication, pretty basic. Front page client talks to the front page server extensions over HTTP put requests. The front page client typically makes requests against author, admin, shtml.exe, as well as the VTIRPC commands. We're going to talk about the different DLLs. The admin DLL is typically used for authoring commands, uploading content, downloading content, reviewing properties, setting permissions. The author DLL is used, like I said, for uploading and adding content. The VTIRPC and shtml are typically used for initial, starting your initial session or beginning access. Alright, there's a lot put on those slides. I'm going to try to break it down for you, but you can go back and read it at your leisure. The authentication system is kind of interesting. It authenticates you every single time you do anything. When you first make a connection, it authenticates. When you scan the directory, it authenticates. When you pull up a file, when you upload or download a file, it authenticates. What it essentially does, the first half of the authentication is let's determine if this is actually is a front page-enabled server. So the first request is a client request for underscore VTI, underscore INF, dot html. Basically, this gives this information on server version. In other words, is this client compatible with this version? It gives me locations for the admin, the author, exe's or DLLs, whatever case that may be. Following this, the client takes this information and makes a post to VTI RPC. It's kind of an initial session start post. It's trying to initiate communication. The server will typically respond with a 200 okay. The client then posts to VTI author or admin, depending on the action. In our example here, it's author. In the case that the administration has elected to allow everyone access, at this point, front page will receive a 200 okay, and you will have authenticated. Otherwise, you'll get kicked back a 401.3 authorization required. At this point, the client knows it needs to communicate to the server. It needs to authenticate so it takes its NTLM. In the case of Windows, it takes the NTLM username and password, builds the NTLM challenge, and sends that back to the server. The server will, once again, respond with a 401.3 authorization required. Except this time, it passes back the server side challenge. This point client now knowing its own username and password and having a specific server challenge pushes back the challenge response. It closes with a 200 okay. It's a very simple system, but it happens again and again and again throughout the process of accessing front page. We'll talk a little bit about VTI INF. This does provide all the configuration information. It's embedded in the comments of the VTI INF.html. If you were to open that page, it would just say front page configuration information. What resides inside that, on the other hand, is actually the comments and they show the location of the file. They show the location of the server, version information, things like that. Alright, like I said before, VTI INF actually gives us a lot of extra information about the server itself. It tells us, believe it or not, tells us the operating system in most cases. The .dls and .exe's can help us determine that. Anytime the VTI INF contains author or admin .exe, nine out of ten times you're dealing with an Apache or a Unix box. Dls, of course, come on the Windows sign. More importantly, the version information can help us narrow down the OS version. This is important for other attacks. I put together a version information table. I was not able to obtain a Windows ME personal server version information. I apologize if the formatting got munged. Windows NT, typically it is a 4.x version. Pretty easy to remember. Windows 2000 and Windows XP both fall under a 5x version, although it's most often than not a much lower subversion number for 2K. It's a 5 for Windows 5.2 versus 5.6 or 5.8 on XP. I didn't create the name. That's Vermeer. But Vermeer created, they call their packets that they cast back and forth, Vermeer RPC packets. Vermeer RPC packets resemble web services. They resemble encoded HTML with variables. In my opinion, it might have been an early precursor to XML. The following is a sample Vermeer RPC packet. It contains a large amount of information. It's a little clearer, I'm sure, on your CD than it is up here. What you'll see embedded down in there is a physical drive path to a file you attempt to download. It's pretty much a big no-no. You really don't want to keep a complete physical drive path to the file. It's possible to use that kind of information for future Unicode exploits. In addition, if you climb in and start reviewing the different information, you'll find a lot of different functions or features, revision level, additional authorizations and permissions, all embedded in those strings. It would be interesting, and it would make multiple attempts to modify different values. I think there are still additional exploits to be had there. Let's talk about the back-end for a minute. One of the more interesting things we were able to do was download a free copy of Microsoft's Windows Debugger, the WinDebug tool. It's a free tool. Microsoft gives it away. Attach that to a back-end running finite info process. Listen as you connect to and make a front-page session to watch what DLLs are being used and what functions the DLLs are calling. You can download WinDebug from Microsoft's debugging site, which I've included here. When you download this, you will also want to enable it to use Microsoft's symbol server. It'll help you translate what functions they're calling. Both the access to the symbol server as well as Microsoft's debugging tool are completely free and a really easy way to get an understanding of what's going on under the hood. Front-page server extensions use, as a partial list of the front-page server extension DLLs, the off-L and AWEL DLLs you'll find are used more often than any of the others. The author and admin DLLs are almost contained stub-like functions that are called and that are used to call functions in the earlier DLLs. I don't know the level of debugging skills, but debugging is an art as well as a science and it takes time to understand it. There are multiple guides and tutorials available on the Internet. A couple of quick Google searches and points you to dozens. WinDebug's got its own set of help files. But I included here the simple commands I used when I was getting started. You can use the VM to set break points and it's kind of interesting. You can give it the DLL and a global variable like star. In other words, in the example I did, fp4awel bang star, it'll essentially set a break point for every single function in that DLL. Now, that's going to hurt because you're going to be stepping through that again and again and again. However, what you're going to get is a list of three, four hundred functions. You can immediately pinpoint and narrow down the functions that seem most interesting to you, such as set permission, get permission, check authorization, things like that. bc to clear those break points. Once you've got your list, print up your list, you go back and highlight the ones you want to set the break point on and then go back and run through and step through the code at those points. She is, of course, go. Once you hit a break, you can restart it with go. He pauses the activity. All right. What did I discover when I went through it? This is just a very brief list, but one of the things that I hit on was the fpawel service actually forms a listing of all documents in the defined web prior to accepting a request. It was my hope that it was coded a little more poorly, that it would write for your request, then go and pull the file and retrieve it for you. However, the server does pre-query the site and then create an array, a stack array listing of these values, and then it will reply with what you, it will search this list when you make a request. However, is there still an opportunity to break out this list? Are there opportunities for the buffer to be overrun? Sure there are. DSP context get file is another one of the get file and get document. They're called when downloading from front page. Set your break points to these and you can step through and figure out exactly where that array is getting called and whether or not there are opportunities for buffer overruns. NTDLL is used exclusively in the authorization process, and we all know that there were attack vectors on that. Microsoft came out and said they will not patch for NT4. If you do the same attack vectors applying via front page, entirely possible. Okay. Taking some of this background information, I learned about front page through my job. I went ahead and put together automated tools to grind through accounts, to grind through passwords, to grind through client front page enabled servers. FP exploiter was what came out of it. It's a really, it's a simple tool. It's a front page password grinding and vulnerability scanner built as both command line and Perl GTK. In other words, now that you have a better understanding of how front page works, let's find out about finding vulnerable targets. This is what brought about the tool. The tool locates front page accessible web servers, uses default options, in other words, tests for the everyone account, then follows up using user defined accounts and passwords. It comes with a default password list. If I recall, it's one of the ones that the, one of the NetBios forums uses. It's a typical simple password list. It's a Perl GTK and a command line tool. When you open it under Linux, you will see a window pretty similar to this. The scanner works by you provided a class C range. You set partners. Yeah, I could definitely have made it a lot larger than that, but most clients only have a class C network and we didn't want to help the script piece out any more than I had to. You can also set the password list. Like I said before, the password list is created initially with a roughly 25 or 30 standard administrator passwords. Very simple things. Password 1, 2, 3, add root. The password list can be modified. Now, keep in mind that using an enormous password dictionary, something on the tune of tens of thousands of passwords, will chew up your memory very quickly. The default account is set to administrator. This was done on purpose. The administrator account does not lock out. If the client has set, has a, has a better account for you to use. If you know that their web, their web administrator uses the account webmin or webadmin or mic, then that would be, of course, the one you would use. Keep in mind that those accounts can be set to be locked out. Again, you can, the tool allows you to save the log. It wouldn't be very useful to me if all I could do was look at it on the screen. So you save the log to text, print it up and add it to your scanning reports. Screen capture during operation. There are more interesting ones on the website. Now, what I didn't cover is that the tool is built for and only runs against IIS-based web servers. I didn't make any modifications to support front-page Apache. The authentication system and the processes are very different. Front-page Apache uses DES or a crypt function on the Unix sign. However, they do store their passwords in individual files. Many times these password files are accessible. So I wouldn't be too surprised if in the next three to six weeks you happen to see a version that supports Apache up on the website. There's also an opportunity to redesign it for generic front-page access. Perhaps the open office guys, if they're listening, are interested in adding front-page-based access to the open office suite. And I'm all for rebuilding it something a little faster than Pearl GTK. Support for uploading content is very close. There's a few Unicode-based characters that Microsoft puts in, but once all of that's been cleared up, I don't see it taking very long. All the code is available at the website. It's on your DEF CON CD, but I recommend you go to the website tomorrow. The code will be unlocked once I've got access to a console. I recommend you go and download that if you plan on using it. That's where the latest code will be. So let's say you gain access to front-page and you're looking at the next steps. In other words, where do you go from here? In a little session we're going to call ASP for hackers. Active Server pages have been around for quite a while. And if you ever take the time to develop any web-based content, ASP is much like PHP. It gives you a lot of options. It gives you a lot of areas you can exploit. You can build some rather impressive administration and control systems straight from a web page. One of the first tools I'm going to talk about is a tool I discovered out on ASP Alliance. Michael Brinkley developed it. Real nice guy. His tool set is rather extensive. It's a SQL Server database tool. If you've ever administered or accessed SQL Server, you've gone and been using Query Analyzer. Most of us folks are command line-driven types. And Query Analyzer allows you to go in and execute all of the administrative queries you would want to do at an account, removing users, analyzing the data. What SQL Ultimate allows you to do is it allows you to run a Query Analyzer session directly out of your web browser. Once you've used your front-page exploiter to find a vulnerable server, you've logged in and uploaded SQL Ultimate. You'll find you're able to access, administer, and control internal SQL Server databases. As most administrators do place the ASA account embedded in the ASP code already on their site. SQL Analyzer, to give you some suggestions, some interesting things to try, adding SQL users is very simple. Most of the time you are part of the ASA role. Accessing corporate data, accessing the back-end to web applications can also be very powerful. You can execute extended store procedures as well as locate application accounts and passwords. Here's a screen capture of SQL Ultimate. You'll see the query window on the left and the resulting window on the right. Go ahead, go over to ASPAlliance.com and check out the stuff that was put together by Michael. He's really done a lot of great work. He was very amenable to me putting it up here. Like I said, there's the link for the ASP Alliance site. Let's talk about command line ASP. This is an old one. It's been out for quite a while, but there are still some folks that don't know about it. I'm going to butcher this poor guy's name or girl's name. Maseo is what I'm going to try. This tool allows for the execution of simple commands on the command line. It's just that basic. Some of the more interesting things you can do with it is connect to netstat minus a, create your own makeshift reverse DNS lookup. Do a netstat minus a, get the names, do a netstat minus n, get the numbers, match the ports, and you've got kind of a makeshift reverse DNS. You can do an IP config, you can do a ver, you can do a set users, you can net users, net local group. Remember that the account permissions that you have typically on a site are when you, when you crack the site or something like local system. However, if you built your own front page site and you set that site to require authentication, the account you log in with is the account you execute these as. Front page explorer helps us find vulnerable web servers. Command ASP.asp contains custom code to execute simple console commands. Now like I said before, you can use a netstat minus a or a netstat minus a n to make a makeshift reverse DNS. You can use net local group and net view to understand drive mappings in groups. It's a very, very powerful option. In fact, many clients in the past have had their web server mapped to multiple internal file servers to make retrieving documents on the website much easier. As well as using ping and defined additional servers. There's a screen capture of the command ASP tool in action. It's a very simple punch in the command and hit go and you'll have the results passed back to you in HTML. The code is not available at my site, of course, it's available at secureteam.com. ASP code can be used in conjunction with Winsot controls to provide scanning from the web server. What I'm talking about here is there are a lot of other options. I've just mentioned too, there's a lot of other things you can use ASP code for. You can upload controls, Microsoft, as well as a lot of other companies have developed web-based controls to do any manner of things and one of which would be a Winsot control perhaps programmatically scan the internal network. There's some really fascinating work being done with ASP.net for Samba shares and remote administration. You can use that tool to reach out and do the same sorts of right-click and administer sort of activities you would do on the internal network. In addition, you can use the ASP code and an XML HTTP control to proxy-surf the intranet. This was a previous client. This was beneficial as the client had mounted web-based cameras in their intranet to provide security monitoring for their employees. So it was very interesting to double-watch their employees go about their business. We're going to close a little early today, I think. I don't want to get the attorneys mad at me. We're going to talk about holding down the cord. How do you secure a front page? You can use simple best practices. As in most systems, your first, last, and primary line of defense is your password. The front page really is no different. You want to choose strong passwords consisting of upper and lower case characters, numbers, special characters. Let's make it something a little more difficult than dog, cat, password, girlfriend's name. I prefer using passwords over eight characters in length. We can go into a lengthy discussion about, well, it only uses the first seven. If you have a 14-character password, it's really like two. That being said, passwords, eight characters in length, typically they're easy enough to remember. You have to remember your own phone number and characters in length, so what's one more? Change the admin account. Contrary to popular belief, Microsoft, actually I encourage you to change the administrator. The name of the administrator account, it will not break all functions. It won't cause the machine to explode. Choose a meaningful admin account, but avoid typical choices like root, admin, supervisor, boss. Concept of least privilege. Only provide the access necessary to get the job done. Use front page roles to assign users author rights versus admin rights. In fact, if there is no reason to have the administrator account have front page access, then pull it. Within front page, there is a, the front page has its own set of permissions. Use the front page permissions tool to add or remove accounts as needed. Pull the administrator account or reserve it for, reserve the front page administration rights for specific accounts. Your best option, and this is my personal favorite, is remind your employees, spending another girlfriend, family members, that you don't use front page from just anywhere. You use it when you are in your corporate office, environment, VPN, secure area. By that, I recommend using the IP based restrictions that are native to IIS. Go and take the admin, author and VTIRPC files and set those to only be allowed access from internal IP addresses only. Consider segmenting your web developers onto a separate segment of your network and allowing that group access to those DLLs only. All right. There's the site. I don't have a lot of artistic talent unlike some of the other folks here. So it's pretty plain, but it contains the code and the commentary and all of the tools packaged both in typical tar GZIPs or RPMs. I want to thank some of the guys who came before me. There's a bunch of front page hacking techs out there on the internet. Some of them are more pertinent than others at this point, but I've included a link to one of them there. The guy's over at the Pearl GTK tutorial. It's been a long time. It was good to get up to speed. And Microsoft put together a pretty big site devoted entirely to front page. It tends to rotate and move around, so you got to pay attention to where it is. But they've got a lot of the back end processes mapped. They talk a lot about some of the VTI information that gets passed back and forth. We'll close with the thanks. Of course, my lovely wife, my boss. It's a shameless attempt to get a race. The graphics designer who did the image, Mike D'Andrea. He's a President Blunderhead. He has a lot of this kind of stuff. I could never have come up with anything like that. Steve Fickle, who did the technical review and the guys over at the GTK tutorial put up with my emails. All right, if you've got any questions. Otherwise, I do want to cede the pool, but the best question does happen to get one of these cellular PC cards. They won't let me keep it, so I have to give it out to someone with an informative and entertaining question. You're close. The difference is the way the information is passed. Front page has a VTI-specific header. It doesn't use a typical NTL and header, so when you go to a website to log in, say you've got a Microsoft and IS site, and the site has authentication required, the authorization string is passed back and forth. It's just an NTLM authorization on the front page side that got their own VTI headers embedded in that. From the standpoint of technology, it's very similar. Or from the standpoint of the headers and the exact style of the information is passed back and forth. It's different. I wish I could answer that. I haven't had a lot of exposure to the .NET platform. I know that the front page is used on both XP and the 2003 server. I know that the DLS have not changed. They're all the same. The tool really hasn't changed a lot in the last five or six years, and with 32,000 of them deployed on last Google search, it's remarkable that it hasn't been more followed than it has. Then most likely, whatever the same rules would apply. The biggest vulnerability, the question was what's the real problem besides passwords and access with the front page? I think we've got that right. The real problem is it's typically not configured. It's typically deployed right out of the box, and the first person to request access for it someone goes in and sets access to everyone. Immediately, within a few weeks, that's forgotten and the site exists. What's interesting is it's not more heavily scanned or it's not more heavily detected. The IIS scanners, I think, will tell you if there's a front page-enabled site, but they won't go any further than that. They won't tell you if it's got a weak password or missing an account or the everyone account is configured. Yeah. Honestly, the guys I wouldn't worry as much about in a professional opinion, the guys I wouldn't worry as much about are the guys that go in and modify their site. If someone goes and modifies my main page, I'm probably going to figure that out pretty quickly with my wife, a significant other, a family member calls and asks me what the heck this is. The guys I'm worried more about are the ones that slip copies of some of these ASP tools deep down in my site, rename them to make them sound like there's something that should be on my site, and it takes me weeks or a well-configured tripwire-like configuration to even find them. That's where the real power is. That's where the real risk is. Yeah. Can we speak to some of the... Yeah, there are some. In the past, you could go to the VTI underscore CNF file for each directory, and of course it would give you a directory listing that would allow you to execute different content from there. I found, I went through, and one of the links that was in here spoke about a lot of the different, a lot of those older exploits. However, from 2K forward, a lot of those rules do not apply any longer. The majority of the clients I was running into were 2K or beta testing O3. I didn't spend the additional time to go in and review those. If you have a client that's on an NT4 or even for all its instant purposes, an ME or Windows 98, it might be worthwhile to go back and take a look at that. However, a lot of those rules don't apply any longer. From what I saw, most of the older vulnerabilities were information leakage or directory scanning, and remember that what I really want to hit on is, the tool gets configured, installed, and enabled more often than not. 32,000 sites on a Google search is enough to kind of make your head spin. When it's there, more often than not, it's completely misconfigured. What you'll find, I'm sure, in this kind of work, is that it's not so much vulnerabilities in systems as it's vulnerabilities in people's ability to manage systems that cause problems. Alright, that's a good question. Here you go. Yeah, go out and enjoy Vegas, alright?