VERT

PCI-DSS v1.1 and OWASP Top 10

2008-07-02T23:41:43Z

Today Jeremiah Grossman posted that the PCI-DSS 1.1 uses the OWASP Top 10 from 2004. This was picked up by Nathan McFeters over on the Zero Day blog... I wasn't aware that this was really a news worthy issue. There are plenty of valid reasons that PCI-DSS should be updated to make use of OWASP Top 10 2007, both Grossman and McFeters point them out. That being said, there are reasons why they do use the Top 10 from 2004. First of all PCI-DSS is a standard... You can't develop a standard if you are changing constantly. PCI-DSS 1.1 was released in September 2006... The current version of the OWASP Top 10 at the time was the 2004 version. So it only makes sense to include it... I'm willing to bet that going forward we'll see the 2007 version used (at least this is something that nCircle has assumed internally for some time now and expects to see in the September update to PCI-DSS (I do believe they are looking at a 2-year update cycle)). After all, OWASP Top 10 is one of the important community driven standards that PCI-DSS looks to for direction and guidance. So yes the information is outdated today but it was the latest available information at the time that PCI-DSS 1.1 was written. Nathan McFeters also makes the comment that this might mean that no standard (i.e. ScanlessPCI) is better... This is ridiculous... I think it's generally accepted that PCI isn't the be-all and end-all for web application security. The goal is to get people thinking about security and moving towards secure coding practices. It's a small start but everything needs a base, and something is better than nothing. I've accepted that I really can't trust any website to be secure... but what I can do is, hopefully, count on them work towards being "more secure". PCI ensures that and in the end I think that's all it's supposed to do. Vendors, consultants, and everyone in between, should always been informing their customers of the latest and greatest (The 2007 version in this case)... nCircle does this and I would assume that everyone else does the same. As well, as I partially mentioned earlier, this is a standard... maintaining the standard with expected updates is the only way that anyone is going to accept this. It's a different realm but think of Microsoft and their monthly patch cycle. They moved to regular, expected updates because that's what people wanted and what people could work with. PCI has to follow the same idea... something that's maintainable, regularly updated but not cutting edge and constantly changing. This is what's going to lead to universal adoption and that is going to greatly benefit the security community. The groundwork that's being laid is about introducing security... not leading security. You can walk away from this post thinking what you want... but keep this in mind; PCI-DSS is about global adoption first and protecting cardholder data second.

Browser Denial of Service Doesn't Matter...

2008-06-27T18:58:39Z

I've been very vocal against Microsoft's move to label Denial of Service as a stability issue rather than a security issue. I fully disagree with this idea, as availability should be just as important as any other security issue. I will say that they appear to have a sliding scale... where some Denial of Service issues are patched and treated as security issues, however I can't help but feel these should all be treated equally. This is something I've addressed in the past (here and here), however I feel the need to bring it up again. Twice I've contact Microsoft regarding Internet Explorer. Twice I've been told that DoS isn't a security issue... I thought about writing up each issue, but instead I feel that a video may better represent these issues. Download the AVI Crash 1 In this video we have a IE7 install and when we visit the page IE crashes. In this case, too much input submitted to a form is the cause of the problem. To accomplish this I've simply created a long string, and used some onload javascript to set a form text input to the value of the long string and then submit the form. This causes a "non-exploitable stack exhaustion" according to Microsoft. However, I consider the browser crashing to be an exploit. Crash 2 In this video, IE7 has been installed immediately after the SP2 install, then we install the latest updates. As you can see, IE crashes when the page is loaded. The page I visit actually wraps a popular website which causes the crash to occur (it requires being loaded a couple of times to induce the crash, so we use a iframe set to width=0 and height=0 and a meta refresh tag). These seem to be Flash related, however I can't visit the Flash website to grab the latest version (it's the page causing the crash). I'll concede that remote code execution is more serious than denial of service, but that doesn't mean we should discount the seriousness of denial of service. As Microsoft has told me these aren't security issues, I felt I wouldn't be remiss in disclosing them now, in fact, I felt that I should disclose them. With more and more people making use of Web 2.0 applications even denial of service to a browser could have disastrous results. As I've mentioned before... Mozilla fixes issues of this nature under a security advisory (example). If Microsoft's primary competition can do it... why can't they?

XP IPv6 DoS & IPv6 Networking Issues with W2K3 and Ubuntu (Also a DoS)

2008-05-13T17:30:19Z

Back in May of 2007, I was doing some research into IPv6. I had a single host (Windows XP SP2) and a IPv6 Router (Server 2K3) and I was publishing addresses via the router. As I was publishing addresses, I started to notice that they were continually being added to the XP host; older addresses never replaced newer addresses and there seems to be no upper limit on the number of addresses. I decided to investigate further and setup a simple loop to publish numerous routes. Interestingly enough every published route was received and recorded by the host. I only tested 7500 addresses but at the end of this I was seeing some interesting results, which I've detailed in the advisory below. Given the results, I decided to contact the MSRC and report it. Since Microsoft's current stance on Denial of Service being a stability issue and not a vulnerability (I guess we've removed A from CIA), they weren't releasing a security advisory for this but instead mentioned that they'd include a fix in XP SP3. They also asked that I follow their responsible disclosure guidelines and not release details until they had patched it. Given that XP SP3 is now floating around publically I wanted to blog to mention this issue, so I contacted the MSRC to ensure that the fix had been included. After about a week, the response I received was that due to an extensive bug list, they decided not to include this fix. Since I had mentioned my desire to blog on this issue, they asked that I send them my blog post for review prior to posting it. Since that's done... I now present you with the mini-advisory that I wrote and shared internally almost 12 months ago. It's nothing amazing on a single XP host but it is obviously an issue. --- Original Mini-Advisory (Sent to Microsoft) --- Title: Minor Denial of Service via IPv6 Address Publication Background: An IPv6 Router (in this case a 2k3 server) will publish an address for every route that it knows. There doesn't seem to be a limit on how many IPv6 Addresses can be published. If you continually add new routes, it will continually publish new routes. Every IPv6 device on the subnet will listen for these published addresses and add them to its interface. What I did: On my IPv6 Router I setup a simple For loop that would effectively add 9999 x 9999 routes to be published, each route would be advertised to the subnet. Command: C:\Documents and Settings\Administrator>for /L %k in (0, 1, 9999) DO for /L %i in (0, 1, 9999) DO netsh interface ipv6 add route 2001:db8:%k:%i::/64 "Local Area Connection" publish=yes Results: So far, I've added ~7500 addresses... CPU utilization on my XP machine receiving the addresses never drops from 100%. What's more interesting though is the output of the two commands below: ipconfig C:\Documents and Settings\Administrator>ipconfig Windows IP Configuration An internal error occurred: The file name is too long. Please contact Microsoft Product Support Services for further help. Additional information: Unable to query host name. netsh interface ipv6 show address C:\Documents and Settings\Administrator>netsh interface ipv6 show address Querying active state... No entries were found. The file name is too long. Caveats: It appears that this only works if the XP hosts are on the network when you are publishing addresses at the time. If you add the addresses and then a new host comes online, it appears to only receive the last ~50 addresses. However if the machine is on the network as each address is published, it seems to obtain every address published and just keeps appending them. May 2008 Updates: I decided to check other operating systems to see how they responded. I went with Server 2003 and Ubuntu (and another XP test case). The results were interesting. It seems as though other operating systems have protections against this flood built in. Server 2003 limits itself to 9600 IPv6 Addresses, and Ubuntu limits itself to 16. Meanwhile, after 24 hours of testing (using the simple for loop described above (which has it's own drawbacks, including the requirement that it add each of these addresses to the IPv6 router -- a program designed specifically to flood these multicast packets out would be much more efficient)) I have published over 20K addresses and the XP host is trying it's hardest to pick them all up. ipconfig and netsh are unresponsive the majority of the time (every now and then it'll successfully print the addresses) and my CPU is constantly held at 100% by svchost.exe (running as SYSTEM). This could be interesting with a large network of XP hosts and a script dedicated to publishing large quantities of IPv6 addresses. Especially since these are small multicast packets with minimal amounts of data contained within them. While you can't flood the 2K3 and Ubuntu systems, something interesting does happen... when they hit their limit they seem to just ignore future published addresses. This could be a potentially bigger problem then simple CPU exhaustion. I will state first that this discussion could be entirely theoretical at this point, as I had a single test case but here's a thought for you. Ubuntu hits it's 16 address limit and Server 2003 hits it's 9600 address limit, what happens next time a valid address is published? Neither of these hosts updated their address lists as I published new ones, suggesting you could deny hosts from learning new addresses. This begs the question, which is the bigger security risk? Flooding your client operating system and forcing 100% CPU utilization or ensuring your server environments can't learn new published addresses.

OWASP Toronto Presentation - Building A Web Spider

2008-05-08T19:21:15Z

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

PCI Requirement 6.6 Update Released

2008-04-22T18:10:01Z

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.

Follow-Up: Microsoft Websites Open to Ethical Hackers

2008-04-22T02:00:37Z

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.

Microsoft is OK With You Finding Flaws in their Websites

2008-04-21T21:08:04Z

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.

Marketing FUD or Useful Comparison? You be the judge.

2008-04-19T17:29:03Z

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.

Hot off the Press -- PCI 1.1 Requirement 6.6 Finally (and Officially) Clarified!

2008-04-16T19:16:45Z

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.

Upcoming MS Tuesday

2008-04-03T19:33:23Z

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

Trust Me: DoS is Dead?

2008-03-06T18:32:50Z

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.

Seamless RDP

2008-01-14T04:44:46Z

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:

Get rdesktop 1.5.0 or later from http://www.rdesktop.org/.
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.
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\\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.

Interning with nCircle

2007-12-20T16:36:35Z

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)

Patch Tuesday - December 2007

2007-12-11T20:47:12Z

Today we see 7 patches, which fix 11 flaws. --- MS07-063 SMBv2 Signing Vulnerability - CVE-2007-5351 Executive Summary: This important security update resolves a privately reported vulnerability in Server Message Block Version 2 (SMBv2). The vulnerability could allow an attacker to tamper with data transferred via SMBv2, which could allow remote code execution in domain configurations communicating with SMBv2. --- MS07-064 Microsoft DirectX Code Execution Vulnerability Parsing SAMI Files - CVE-2007-3901 Microsoft DirectX Code Execution Vulnerability Parsing WAV and AVI Files - CVE-2007-3895 Executive Summary: This critical security update resolves two privately reported vulnerabilities in Microsoft DirectX. These vulnerabilities could allow code execution if a user opened a specially crafted file used for streaming media in DirectX. If a user is logged on with administrative user rights, an attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights. --- MS07-065 Message Queuing Service Remote Code Execution Vulnerability - CVE-2007-3039 Executive Summary: This important security update resolves a privately reported vulnerability in Message Queuing Service (MSMQ) that could allow remote code execution in implementations on Microsoft Windows 2000 Server, or elevation of privilege in implementations on Microsoft Windows 2000 Professional and Windows XP. An attacker must have valid logon credentials to exploit this vulnerability. An attacker could then install programs; view, change, or delete data; or create new accounts. --- MS07-066 Windows Kernel Vulnerability - CVE-2007-5350 Executive Summary: This important security update resolves a privately reported vulnerability in the Windows kernel. An attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full administrative rights. --- MS07-067 Macrovision Driver Vulnerability - CVE-2007-5587 Executive Summary: This important security update resolves one publicly disclosed vulnerability. A local elevation of privilege vulnerability exists in the way that the Macrovision driver incorrectly handles configuration parameters. An attacker who successfully exploited this vulnerability could take complete control of the system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. --- MS07-068 Windows Media Format Remote Code Execution Vulnerability Parsing ASF - CVE-2007-0064 Executive Summary: This critical security update resolves a privately reported vulnerability in Windows Media File Format. This vulnerability could allow remote code execution if a user viewed a specially crafted file in Windows Media Format Runtime. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights. --- MS07-069 Uninitialized Memory Corruption Vulnerability - CVE-2007-3902 Uninitialized Memory Corruption Vulnerability - CVE-2007-3903 Uninitialized Memory Corruption Vulnerability - CVE-2007-5344 DHTML Object Memory Corruption Vulnerability - CVE-2007-5347 Executive Summary: This critical security update resolves four privately reported vulnerabilities. The most serious security impact could allow remote code execution if a user viewed a specially crafted Web page using Internet Explorer. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

Q: When is a Vulnerable Application not a Vulnerable Application?

2007-12-10T16:31:13Z

A: When the vulnerable component is a third party addon. It seems that quite a few people are talking about a Stack Overflow that appeared on milw0rm over the weekend. ISC posted on it, SecurityFocus has added it as a vulnerability and assigned an Bugtraq ID to it and Donna's SecurityFlash has picked it up. Shortly after the ISC post went up, I sent an email to them via their contact form, letting them know that this wasn't a vulnerability in Windows Media Player 6.4. They have finally updated their content to reflect this, but others still haven't... so consider this an update to all those other sites. This vulnerability affects the 3ivx codec pack and specifically 3ivx.dll. Windows Media Player 6.4, which is found on all versions of Windows up to, and including, Windows Server 2003 doesn't support natively support mp4 files, which is the file format generated by the PoC. According to the individual that discovered the vulnerability, the latest release (5.0.1) is vulnerable to this flaw.