A couple of weeks ago I spoke at OWASP Toronto. My goal was to lead a discussion on building a web application spider... what you had to consider, pitfalls to avoid and so forth. I felt like it went fairly well, the discussion lasted about an hour and there was quite a bit of group interaction. I picked up some interesting things from the attendees and I'm hoping that they picked up some interesting ideas from me. At the end of the discussion, I was asked if I could make the slides and the sample source (for a very basic spider) available. So here they are.

PowerPoint Presentation
Simple Spider written in Python

It looks like the PCI Security Standards Council has posted their update to Requirement 6.6 (available here). They have provided information above and beyond what I mentioned last week. They have also provided a great deal of clarification around Web Application Firewalls.

Some interesting notes:

• Reviews can be performed by qualified internal or external individuals. However, internal auditors should not fall into the same organizational unit as the developers.


• There is text that identifies examples of where reviews will meet or exceed the quality of Web Application Firewalls. The two provided examples are:
  
  • Security reviews of source code during the development process.
  
  
  • Testing for the presence of web application vulnerabilities either manually or via a specialized tool


• Testing must occur prior to the Web Application going live (Note: Of course this doesn't mean testing should stop there, on going testing is key. As Braden Williams put it today, "You have to MAINTAIN what is assessed")

Trey Ford has a great write-up and answers some additional questions that people may have... I highly recommend reading it.

I blogged earlier today about this story posted on The Register regarding Microsoft's promise to not sue or press charges against ethical hackers reporting flaws in their websites. It's been picked up by a number of people, including Ryan Naraine, Dave Lewis and LinuxSecurity.com.

I wanted to know more on the subject, so I decided to contact Microsoft directly and ask for official clarification (since I wasn't at Toorcon to hear it first hand). The response came from Bill Sisk, Microsoft Security Response Communication Manager. Bill had the following comment:

Microsoft did not announce anything new at ToorCon Seattle regarding its position on responsible disclosure, but we did mention our industry leading online services acknowledgement, which went public in July of 2007. Because we will not pursue legal action against researchers who report vulnerabilities to us responsibly, we hope to encourage those who want to help us protect customers to feel free to do so without fear of repercussions.

As we have done for many years, we continue to work closely with security researchers and encourage responsible disclosure of vulnerabilities in our products as well as for online services. If a vulnerability is responsibly disclosed, we will publicly credit the researcher for his/her assistance. We believe responsible disclosure serves everyone's best interests, by helping to ensure that customers receive comprehensive, high-quality updates for security vulnerabilities with no exposure to malicious attackers while the update is being developed. For additional information on how Microsoft credits researchers for responsibly disclosed online services security vulnerabilities, visit: http://www.microsoft.com/technet/security/acknowledge/faq.mspx.

So it looks like this has existed for a while, and has just been overlooked (or perhaps forgotten); either way, it's great to see that Microsoft has the FAQ available on their website and, as Ryan pointed out on SecurityWatch, has setup a page to acknowledge people who responsibly disclose vulnerabilities in online services.

There's an interesting story up on The Register from Toorcon. Since I wasn't at Toorcon, I can't confirm it, and I haven't seen any other stories that don't solely reference The Register's article.

Katie Moussouris, a Microsoft security strategist, told the crowd that Microsoft would not sue or press charges against ethical hackers who report security flaws in their websites.

This is a huge move in the right direction in my opinion. Web security is something that plagues almost everyone and it's good to see Microsoft making a move to improve their web security. Let's hope that more companies will follow Microsoft's move.

Let's also hope that Microsoft puts out something official on this subject, because so far... the only original piece I've seen is The Register's article.

If more comes on this subject, I'll be sure to blog about.

A couple of days ago Digital Bond posted a short blog post on Server 2008 Core. They had written about it previously and done a podcast (One of their partners is developing software to run on Server 2008 Core). One of the common themes for Server 2008 Core is the limited attack surface that it presents, as it essentially "console-only". Actually everyone refers to it as an OS without a GUI, yet cmd.exe is open as a window that you can minimize/maximize and you can run task manager, notepad, regedit and a couple of control panel applets, but close enough I suppose. Also when logging in you get "Preparing your desktop"... really all "GUI-less" means is explorer.exe isn't around. Also folders in C:\Users\administrator: Saved Games, Music, Pictures, Links, Favourites, Videos (etc). Alt+Tab still works as well (with a GUI showing you icons).

Anyways, in this Digital Bond blog post, they talked about how the decreased attack surface meant that out of the 25 security bulletins released by Microsoft only 4 would apply to Server 2008 Core. The problem with that? Only 4 of the advisories applied to Server 2008 at all... so Digital Bond has just said that Server 2008 and Server 2008 Core had the same number of patches.

As a side note the decreased attack surface for Server 2008 Core seems to really be on the client-side. I counted 20+ running services on a fresh install, including services like Remote Registry (which doesn't even run on Vista by default) are running on Server 2008 Core.

The four updates that affected Server 2008: MS08-021 (GDI), MS08-023 (ActiveX Killbits), MS08-024 (IE), MS08-025 (Windows Kernel Privilege Escalation).
The three updates that installed on Server 2008 Core: MS08-021, MS08-024, MS08-025.

So 75% of the patches released for Server 2008 also apply to Server 2008 Core... but let's think about this:

• Server 2008 allows you to disable metafile processing, mitigating MS08-021.


• Server 2008 has IE7 which has the affected ActiveX control in MS08-023 disabled by default and Yahoo! Music Jukebox wouldn't be installed on a server (unless you weren't using it as a server).


• With MS08-024 we're back to IE again... Why are you using IE on your server in the first place?.


• With MS08-025 this is local and credentialed, which generally implies insider threat.

So out of the 4 patches, only one isn't mitigated by practical server hardening... and that patch applied to both Server 2008 and Server 2008 Core. I'm not sure why Digital Bond was making a big deal out of "only 4 would apply to Server Core.", one thought might be they are pushing their partners product but a more likely thought is that they were saying *IF* (and that's a big, and useless if) all 25 bulletins applied to 2008, only four would have applied to 2008 Core.

[Disclaimer, I would never attempt to do this if I didn't think it was the only semi-plausible explanation for their report]
Well let's think about that... We can immediately eliminate all the Office patches (Common Sense: You don't install Office on a server). That leaves us with 15 / 25 (10 are pure office only). Out of these 15, we know that MS08-025 existed, and MS08-002 was also privilege escalation and it affected lsass (which exists on Server 2008 Core... So that gives us 2 / 13 / 10 (possible, undecided, impossible). We also saw that the IE patch was installed... so let's accept that one all the way across. That's another 2... bringing us up to 4 / 11 / 10. We know that GDI was installed... that's 5 / 10 /10. I have confirmed that wscript exists (even though it is 5.7... let's follow the rules and include it as a "possibility")... that's 6 / 9 / 10. There are two TCP/IP and one AD, so we'll include those... that brings us to 9 / 6 / 10. Now IIS exists on Server 2008 Core, so we'll have to include those two bulletins. That brings us to 11 / 4 / 10. Now the ActiveX Killbits update wasn't installed -- 11 / 3 / 11, and that leaves us with WebDav Mini-Redirector, OLE Automation and DNS Spoofing. DNS Spoofing we'll put on the yes side... 12 / 2 / 10. Web-Dav redirector I'll assume doesn't exist -- 12 / 1 / 11 and OLE Automation... well the DLL exists in Server 2008 Core... so I'll go yes.. 13 / 0 / 11.

That means that *IF* we had taken this approach to determine the size of the attack surface (which means assuming vulnerable versions of software which don't exist on Server 2008), that 13 out of 25 Bulletins would have applied.

So in the end, I'm not sure how Digital Bond came up with 4... however I'd love it if they shared their process. Does Server 2008 Core have a smaller attack surface... theoretically, however I'm not sure if the attack surface is any less than that of a properly hardened and maintained Server 2008 install. In fact, as I pointed out earlier (with Remote Registry) in some cases it's less secure than previous versions of Windows. This doesn't mean people shouldn't use Server 2008 Core, they should just make sure they have a full understanding of what's happening in their environment and not take advantage of Server 2008 Core as an alternative to hardening their server properly.

I just got an email from my director who's attending a PCI event in Las Vegas. It seems that the PCI Standards Council has finally released clarification to the often-debated Requirement 6.6 of the PCI SSC. In this section, the standard currently identifies two options: Application Code Review or implementation of Web Application Firewalls. The PCI DSS Information Supplement was completed in February and has a Release Date of April 15, 2008 (yesterday). It is scheduled for publishing online within the next week or so. Here is a snippet from the document:

The application code review option does not necessarily require a manual review of source code. Keeping in mind that the objective of Requirement 6.6 is to prevent exploitation of common vulnerabilities (such as those listed in Requirement 6.5), several possible solutions may be considered. They are dynamic and pro-active, requiring the specific initiation of a manual or automated process. Properly implemented, one or more of these four alternatives could meet the intent of Option 1 and provide the minimum level of protection against common web application threats:

1. Manual review of application source code
2. Proper use of automated application source code analyzer (scanning) tools
3. Manual web application security vulnerability assessment
4. Proper use of automated web application security vulnerability assessment (scanning) tools

I think that we'll see a lot of good come out of this... it really broadens the options of what companies can and cannot do to satisfy Requirement 6.6. This doesn't mean that static source code review should be forgotten or discarded, only that there's now a cost effective option between the two previous options. This will benefit a number of companies, giving them an alternative that isn't as expensive as a manual source code review and also doesn't depend on the company's specific configuration of a web application firewall (Chris Eng of Veracode has a great post on why WAFs just don't cut it).

This also seems to be the exact opposite of what Jeremiah Grossman interpreted Bob Russo's recent quote as meaning. Instead of narrowing the definition the PCI Standards Council has broadened the definition. I guess this is the update/clarification that they mentioned in their response to Dennis Hurst last year.

Hats off to Dennis Hurst, Jeremiah Grossman and others in the industry, along with the PCI Security Standards Council. Many of us have been lobbying for clarification to these requirements and this is a perfect example of how things can improve if you have input from industry experts and responsiveness from the standards bodies. I won't get into debating the "responsiveness" side of the equation in this post, but the update has been made so let's move forward.

In the end though, it's up to the company interested in becoming PCI certified to decide which approach is the right one to take. While I'm sure a number of companies will appreciate this new option, many will deploy web application firewalls, and I'm sure many will still want the peace of mind offered by an exhaustive static code review.

From here

We have the following this month:
5 Critical
3 Important

Details:

Bulletin 1 (Critical - Remote Code - Office)
Affects:
- Microsoft Project 2000 SR1
- Microsoft Project 2002 SP1
- Microsoft Project 2003 SP2

Bulletin 2 (Critical - Remote Code - Windows)
Affects:
- Windows 2000 SP4
- Windows XP SP2
- Windows 2003 SP1 & SP2
- Windows Vista Release & SP1
- Windows Server 2008

Bulletin 3 (Critical - Remote Code - Windows)
Affects:
- VBScript 5.1
- VBScript 5.6
Operating Systems (2000, XP, 2003)

Bulletin 4 (Critical - Remote Code - Windows / IE)
Affects:
- IE 5.01
- IE 6 SP1
- Affects all Operating Systems as well as the W2K Browsers
Operating Systems - ALL

Bulletin 5 (Critical - Remote Code - Windows / IE)
Affects:
- IE 5.01
- IE 6 SP1
- IE 7
Operating Systems - ALL

Bulletin 6 (Important - Spoofing - Windows)
Affects:
- Windows 2000 SP4
- Windows XP SP2
- Windows 2003 SP1 & SP2
- Windows Vista Release & SP1

Bulletin 7 (Important - Elevation of Privilege - Windows)
Affects:
- Windows 2000 SP4
- Windows XP SP2
- Windows 2003 SP1 & SP2
- Windows Vista Release & SP1
- Windows Server 2008

Bulletin 8 (Important - Remote Code - Office)
Affects:
- Visio 2002 SP3
- Visio 2003 SP2
- Visio 2003 SP3
- Visio 2007
- Visio 2007 SP1

Security is an interesting thing... it's a field that leaves a lot open to interpretation and in many ways each vendor is allowed to answer the same question differently. Today we'll ask the question, "What warrants a security advisory?" That seems like a straight forward question, so let's put it to the test with two popular browsers: Microsoft Internet Explorer and Mozilla Firefox. Now I feel as though I should preface this by saying that I use Firefox on a daily basis, but that is only because it is cross platform and I have Windows and Linux at work, and Windows, Linux and OS X at home. However, I'm also a big fan of Microsoft as I think previous posts here, and on my personal blog, have demonstrated. So we're not making war with either side here... we're just examining the different responses to the same question. (Note: Neither Microsoft nor Mozilla were consulted, the responses are just my interpretation of their action/inaction.)

So back to the question, "What warrants a security advisory?"

Let's take a look first at Mozilla Firefox. The Mozilla Products Known Vulnerabilities page is one that I am quite familiar with, and a huge fan of. I love the presentation and the layout. What's interesting is that nearly every release contains a very familiar security advisory title, "Crashes with evidence of memory corruption." When you look inside these, they are essentially stability improvements. Yet Mozilla acknowledges that they can crash the browser and they recognize a crash as a security related issue. Another example, to pick one at random, is "Persistent AutoComplete Denial of Service." In this example, millions of characters typed into a form and stored can cause the browser to hang. Not even a crash this time, simply a hung browser and again Mozilla has decided to address this with a security advisory. It seems to me that Mozilla accepts that a Denial of Service warrants a security advisory.

Next up to bat... Microsoft Internet Explorer. Microsoft seems to have taken a very different approach; Microsoft considers a Denial of Service (or "crash") to be a stability issue. These stability issues are not security issues but rather bugs. I know what you're thinking, quite a few security issues are bugs and I would tend to agree... Microsoft, however, would not. Now you are probably asking what evidence I have that Microsoft considers stability issues to simply be bugs that aren't security related. That's simple. I contacted Microsoft security to report a crash condition with regards to IE7. The crash condition can be reproduced reliably and happens to be discussed (briefly) on a few pages regarding web development. Microsoft's response (paraphrased), "This is a bug, report it to the IE team." (Note: this may actually be an Adobe issue in the end; I didn't pinpoint the line of code in the pages responsible for the crash. However it is specific to IE7, in a specific situation. Which at the very least warrants investigation in my eyes.)

This strikes me as a pretty big distinction between what two vendors warrant worthy of a security advisory versus non-security bugs. For the most part, this isn't the sort of thing that would get under my skin if others in the industry weren't drawing misleading conclusions from it.

In a recent article, a claim was made that IE was the most secure browser of 2007. From what I can see, this was based mostly on the number of vulnerabilities reported in various browsers last year. As a Security Researcher, this irks me to no end to see such a sweeping conclusion thrown out for public consumption without first doing research. I can't imagine someone making such a claim based on a simple vuln count if they knew that Microsoft had redefined DoS conditions as non-Security issues - and I can't imagine someone claiming to be an expert on browser Security without knowing this.

Some may say that this is an isolated case by Microsoft with their browser, but the same trend seems to have emerged in other Microsoft technologies - including XP. The only difference in this case is that the author has web technology tunnel vision. At least in this case, their short sightedness limited how much misleading information they put out there.

At the end of the day, DoS is DoS. If one vendor redefines DoS as a non-security issue, those dishing out Security advice need to apply the same definition to competing products. The last time I checked, Security included consideration of confidentiality, integrity, and availability. Agree or disagree, but apply your definition to all products in the space.

My advice is to be careful about taking opinions from "Security Experts" as gospel. If our ramblings inspire you to dig deeper, then we're doing some good. If they don't, we're all worse off.

I was having an issue with rdesktop locking on under Ubuntu, so I did some research... I wasn't running 1.5.0, so I upgraded and while reading I found out about SeamlessRDP.

SeamlessRDP allows you to run indvidual applications via RDP instead of your full Windows Desktop. Cendio, the creator of SeamlessRDP lists the following steps:

1. Get rdesktop 1.5.0 or later from http://www.rdesktop.org/.
2. Get the server side component, "seamlessrdpshell". It is available in the seamlessrdp CVS module. You can also download a pre-built binary from http://www.cendio.com/files/thinlinc/seamlessrdp/seamlessrdp.zip . Unpack the files to some directory on the server, such as c:\seamlessrdp.
3. Run rdesktop with: rdesktop -A -s "c:\seamlessrdp\seamlessrdpshell.exe notepad"

They do forget one key thing:

The user you want to use requires a NoDesktop key set.... This key is found at HKEY_USERS\<USER SID>\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer or HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer (if you are logged in as the user). NoDesktop will need to be created as a DWORD Value and set to 1.

You are now ready to run SeamlessRDP... I recommend using the run command box (Generally Alt+F2) rather than a console so that the massive amount of error messages don't scroll across the screen (these error messages are ok to ignore). You can run individual applications as Cendio described above... don't forget to provide the IP Address at the end of the command. However, something I enjoyed doing was running explorer.exe... a Windows start menu appears above your Linux Window Manager menu. You can navigate the start menu and launch applications, running them as if they were local.

Now I was experimenting with this over VPN and I did find it slower than RDP... I'm using Ubuntu and I've noticed that SeamlessRDP doesn't play well with Gnome... a single application runs great but if you want to do the explorer trick, you have to open programs, log off and then log back on, Gnome doesn't seem to properly allocate windows when you launch programs. On a LAN the speed seems to be just fine.

Also with Gnome... You will have redraw issues with your Windows start menu, if you have your Gnome taskbar touching the bottom of the screen... your best bet is to put your Gnome taskbar docked next to your Gnome start menu on the top of the screen.

I'm going to keep playing and I'll post any other tips or tricks that I discover.

As 2007 nears its end, so does my internship with the Vulnerability Engineering and Research Team (VERT) at nCircle. I cannot believe how much I have learned since starting last May. Operating systems I had never heard of, advanced Apache and IIS webserver administration, random protocols (SMB, FTP, HTTP, SSH), Reverse Engineering... it seems like everything but the kitchen sink.

Every other day, a new "high priority" vulnerability was reported that kicked VERT into high gear, sending the team into a dizzying rush to write detection for it. What amazes me is how they can juggle these last-minute high-priority rushes while keeping standard coverage projects going on the side. The VERT members managed to juggle both of these and each were still able to find time to pull me aside and train me in everything from Python to Reverse Engineering.

Unlike my past internships, I was very pleased to be able to have the opportunity to accomplish a wide variety of tasks at nCircle instead of sticking with one task throughout the term. I spent 4 months on the testing (QA) side of VERT, and 4 months on the dev side, giving me the opportunity to doublecheck vulnerability detection rules, and then write my own. I was worried that joining a team like VERT would make them hesitant at using me as a resource due to my comparative lack of knowledge, but thankfully that wasn't the case. I was given work just as challenging as the work I saw them doing, and although it may have taken me a little longer to complete since it was my first time doing it, they were patient enough to wait for me to get it done on my own without butting in and doing it for me. This provided me with a challenging environment (which I love!) giving me a chance to learn... and a chance to get tripped up by their constant quizzes: "Are you SURE it works like that? I already know the answer, but I won't tell you. Figure it out for yourself!"

After working in such a fast-paced environment, I'm not sure how I will be able to transition back to a classroom setting to complete my final 8 months in my Information Systems Security degree. One thing I do know is, the knowledge I've acquired while working on VERT for the last eight months has added more value to my degree than any other classroom semester to date.

Thanks VERT, thanks nCircle, have a great Holiday and see you next year!

--Michael Perklin (aka Steve the Intern)