Tampilkan postingan dengan label TTP. Tampilkan semua postingan
Tampilkan postingan dengan label TTP. Tampilkan semua postingan

Rabu, 05 September 2007

Hardware-Assisted Virtual Machine Rootkits

Thanks to www.rootkit.com I learned of a new paper by Michael Myers and Stephen Youndt titled An Introduction to Hardware-Assisted Virtual Machine (HVM) Rootkits. Like most good papers they discuss the underlying technology before explaining how to exploit it. I selected a few choice excerpts.

HVM rootkits, theoretically at least, are not vulnerable to any action the operating system can take since the rootkit runs in a more privileged state than the OS. A hypervisor need not even exist in memory that is accessible to the operating system. When a hypervisor bootstraps itself, it makes any instructions or memory accesses which could betray its existence more privileged than the operating system. When these instructions occur, the processor traps to the hypervisor, allowing it to modify the results. Thus, the hypervisor need not make any changes to the operating system to hide its own presence. The hypervisor can, however, make any such changes with impunity and make them undetectable by the operating system...

Unlike the typical hypervisor which loads before it starts its guest VM, an HVM rootkit loads into an already loaded operating system and turns it into its guest VM. Therefore the rootkit must initialize the hypervisor functionality and dynamically take over as host, turning the running operating system into a guest. This process has been repeatedly referred to as “forking” or “migrating” the OS to a guest state, but these terms are misleading.

The hypervisor and OS do not run concurrently (as they would if they were “forked” in the UNIX sense) nor does the OS need to be altered or moved in any way (“migrated”). The process of installing an HVM hypervisor in a running OS is more like that of installing a “shim,” in the software engineering sense of the word. A shim is a piece of code between two layers, in this case between the CPU and all other software running on the system.

At this stage, the practical detectability of HVM rootkits is still hotly contested. The trend is clear, however. Researchers are continually suggesting new detection methods, and the code required in the HVM rootkit to evade each one is successively layering more and more complexity into the rootkit’s design. Paradoxically, the more complicated an HVM rootkit must be to avoid known detection schemes, the more presence it has within the system to have to work to hide...

[T]he popular consensus has been that HVM rootkits will eventually become too difficult or costly to implement, or even that they are ultimately unfeasible. One might point to the fact that there are no known HVM rootkits in the wild. But neither are there any HVM rootkit detectors to find them if there were...

If detection of an HVM rootkit is difficult and impractical, actually procuring a forensic copy of an active HVM rootkit may very well be impossible. The HVM rootkit only needs to exist in RAM, meaning a forensic examiner is tasked with obtaining a copy of all of physical memory in order to search for the presence of an HVM hypervisor...

There are two common approaches to imaging physical memory. One approach is to run software on the local system which accesses physical memory through an operating system hardware interface layer. In this case, an HVM hypervisor is able to intercept and control access to the physical memory by way of its exception conditions. It could present the pages of memory containing its hypervisor code to appear to contain all zeros or all ones, for instance. This subversion of memory would go unnoticed by the forensic capture process.

The second approach to imaging physical memory is to take advantage of the abilities of certain hardware peripheral devices that can perform Direct Memory Access (DMA), that is, devices which can read and write system memory without intervention by the CPU. Normally, this would be the most reliable and forensically sound method for capturing he contents of physical memory. However, AMD-V introduces a feature to secure the system memory against any unwanted access from DMA devices.
(emphasis added)

Two years ago during the rise of the public Windows kernel-mode rootkit, I wrote Rootkits Make NSM More Relevant Than Ever. Several years ago we passed the point where suspected compromised hosts could be trusted to accurately report their own integrity to tools running on the victim. HVM rootkits only sink the problem deeper into the platform.

If you're relying on a host to reliably report its security posture, you are bound to be disappointed. You have to complement that host-centric view with an outside view, like that depicted in my TaoSecurity Enterprise Trust Pyramid. Obviously a look at network traffic will not be 100% conclusive, but it will give you a trustworthy vantage point for very little investment of resources.

Jumat, 06 Juli 2007

ARP Spoofing in Real Life

I teach various layer 2 attacks in my TCP/IP Weapons School class. Sometimes I wonder if students are thinking "That is so old! Who does that anymore?" In response I mention last year's Freenode incident where Ettercap was used in an ARP spoofing attack.

Thanks to Robert Hensing's pointer to Neil Carpenter's post, I have another documented ARP spoofing attack. Here a malicious IFRAME is injected into traffic by ARP spoofing a gateway. We cover that in my Black Hat class, both of which are now officially full.

Please remember that TCP/IP Weapons School is a traffic analysis class. I believe I cover the most complicated network traces presented in any similar forum. All you need to get the most out of the class is a laptop running a recent version of Wireshark. The class is not about demonstrating tools or having students run tools. Other classes do a better job with that sort of requirement. The purpose of this class is to become a better network security analyst by deeply understanding how certain network-based attacks work. I provide all of the information needed to replicate the attack if so desired, but that is not my goal.

Selasa, 19 Juni 2007

Web-Centric Short-Term Incident Containment

You may have read Large Scale European Web Attack from Websense and other news sources. One or more Italian Web hosting companies have been compromised, and the contents of the Web sites they host have been modified.

Malicious IFRAMEs like the one below are being added to Web sites. These IFRAMEs like to malicious code hosting by a third party under the control of the intruder. When an innocent Web browser visits the compromised Web site, the browser is attacked by the contents of the IFRAME. This is not a new problem. I responded to an intrusion in 2003 that used the same technique. It's the reason why I discussed having the capability to use an extrusion method to modify traffic as it leaves a site. This is an example of Short Term Incident Containment. This technique does not remediate the compromised Web sites or Web servers. It does help clean malicious traffic before it reaches Web browsers. I suggest using Netsed or Snort in inline mode to replace the malicious IFRAME with something benign. It would be helpful to have this sort of capability widely deployed as an application-level incident response tool.

Note: I do not use Gentoo. However, Gentoo's package site nicely provides images for all the tools in their repository. When one is trying to write slides and add images that have some relationship with the material at hand, Gentoo's "package boxes" make nice additions.

As a preventative measure on the Web client side, Greg Castle's Whitetrash would help prevent the third-party content being loaded into the IFRAME.

On a somewhat related note, I am glad to see developments like that from Palo Alto Networks, described by Dark Reading. It's a firewall that makes blocking decisions based on application recognition, not port number. Parts of this functionality are available elsewhere, but eventually all network blocking and inspection products will make decisions using the same method.

Rabu, 30 Agustus 2006

Attacks Against WEP and Bump Keys

Any security professional should know that Wired Equivalent Privacy is broken. However, thanks to Alan Saqui's blog I learned of another attack method that completely devastates WEP.

At almost the same time Brandon Greenwood sent me a link to this YouTube video about bump keys. This is an attack against physical locks that succeeds with minimal effort against most locks on the market. It was publicized in the United States at Hope 6 last month by Barry Wels of The Open Organization of Lockpickers (TOOOL) and Marc Tobias. MSNBC and Slashdot ran stories, and this week a NBC affiliate reported on the problem as well. This week Marc Tobias is blogging on the subject, and I've learned that locks by Abloy and Medeco are resistant to bump keys. Finally, the blogosphere has some commentary on the problem.

It seems to me that attacks against WEP and bump keys are examples of the same problem. In either case, a determined intruder with sufficient tools and expertise is going to overcome your preventative security measures and compromise you. In my books I call this fact prevention eventually fails. Eventual compromise is the reason I recommend detection and response, as well as insurance.

However, relying solely on WEP while the front door to your data center is propped open is no better than installing a vulnerable door lock on a shoddy frame. In those cases, addressing the popular flaw (vulnerable WEP, vulnerable door lock) still leaves many other avenues of attack open. Most opportunistic wireless intruders will pass a WEP-encrypted network for one that is wide open. Most opportunistic physical intruders will pass a locked door for one that is wide open.

In both cases, fighting the battle to address vulnerabilities is a losing cause. Removing threats by prosecuting criminals is the most effective way to reduce risk.

I feel better knowing I have a big dog in my house, though.

Minggu, 27 Agustus 2006

Why 0wn When You Can XSS

The creative Russians at Security Lab posted word of two more high-profile sites with Cross Site Scripting (XSS) vulnerabilities. They used this announcement to demonstrate problems at CBS News and the BBC.

The URL they provide for CBS is:

http://www.cbsnews.com/stories/2002/02/15/weather_local/main501644.shtml?zipcode=1 \
--%3E%3Cscript%20src=http://www.securitylab.ru/test/sc.js%3E%3C/script%3E%3C!--

(Remove the space and \ to make the URL one big line.)

Looks like there's a problem with the zipcode part of the site through which one can check local weather.

The URL for the BBC is similar:

http://www.bbc.co.uk/bbcone/listings/index.shtml?service_id=4223&DAY=today %22%3E%3Cscript%20src=http://www.securitylab.ru/test/sc.js%3E%3C/script%3E%3C!--

(Remove the space and \ to make the URL one big line.)

The file sc.js that they retrieve has the following:

document.write('<p align=left>Mon, 28 August 2006');
document.write('<p align=center><b>George Bush appoints a 9 year old to be the chairperson of the Information Security Deportment</b>');
...truncated...

The net effect is demonstrated by these screen captures for CBS News and the BBC.

Yes, the use of sc.js means you could replace the URL http://www.securitylab.ru/test/sc.js with one of your own, causing your custom news to be placed at either site -- until they disable the functionality or remove the vulnerability.

Eight to ten years ago Web defacements were the rage. They seemed to get less attention as the major players removed traditional means of exploitation. As Web sites have become more complex, intruders are finding new ways to abuse them. While this is less of a defacement and more of a dynamic presentation of attacker information, it's still a big problem. Think of the havoc false information could temporarily cause.

People already shouldn't trust what they read in emails. Soon they may lose trust in what they read on Web sites.

Jumat, 28 Juli 2006

SPI Dynamics JavaScript Scanner

Ok, this is a little weird. Thanks to SecurityMonkey I just tried the SPI Dynamics JavaScript Scanner. From that page:

Imagine visiting a blog on a social site like MySpace.com or checking your email on a portal like Yahoo’s Webmail. While you are reading the Web page JavaScript code is downloaded and executed by your Web browser. It scans your entire home network, detects and determines your Linksys router model number, and then sends commands to the router to turn on wireless networking and turn off all encryption. Now imagine that this happens to 1 million people across the United States in less than 24 hours.

This scenario is no longer one of fiction.


I recommend reading the white paper (.pdf). I tried out the proof of concept on Windows 2000 as a non-admin user running the latest Firefox. Here's what I got. Now all three hosts exist, but due to known issues none are correctly detected. Still, this is a cool idea. Note that I ran the page while using a Web proxy, so all of the requests went through that device.

Jumat, 31 Maret 2006

Controlling Bots with Steganography

My friend John Ward posted a discussion of controlling bots with steganography:

So basically, all this does is open a Bitmap file, decode the stenography message, and pass the resulting message to the protocol class for handling. More sophisticated techniques can be employed, and steganography has grown as a field, so different graphics formats, MP3 files, or even specially encoded HTML headers can contain the message.

This deviates from the traditional botnet where the client connects to an IRC channel or some other central media to receive commands in real time. In this method, the attacker loses real-time response and gains stealth. With a reasonable interval of time set for the clients, the attacker can have their nefarious commands executed in a short amount of time.

By combining this code with some disguised distribution method, lets say an image thumb-nail browser for an online graphics catalog, the program can be distributed widely, and its online image grabbing behavior would never be suspect until the mass traffic adding to a DDOS attack came from the client machine. And even if it were, your normal Net-Sec analyst would only see an image file and have no clue that the image file contained a steganography-encoded message.


Neat idea John -- is anyone seeing this in the wild?

Senin, 07 November 2005

Websense ToorCon Presentation

Thanks to a comment from Shahid for pointing me to the WebSense Security Labs presentation The Web Vector: Exploiting Human and Browser Vulnerabilities (.pdf). I think the most interesting part of the briefing is the introduction of Web-based bot net command and control. Because organizations are locking down outbound IRC, bot net controllers are using HTTP as a replacement protocol. If anyone has any experience with this sort of traffic, I would be interested in hearing from you.

Selasa, 14 Juni 2005

HTTP Request Smuggling

You may have seen this on Slashdot, but Garth Somerville sent me this link to a paper titled HTTP Request Smuggling (HRS) by Watchfire. You may remember Watchfire as the company that bought Web application security vendor Sanctum. Essentially HRS relies on sending conflicting values or malformed input in HTTP headers. Just as we saw years ago with IDSs, bad results happen when one product interprets commands on way and another product sees the world in a different way. I was pleased to see the Squid proxy server already addressed any problems back in April in two advisories.

The answer is strict HTTP parsing, but rest assured many products will continue to let malformed protocols pass. This is another case where a small set of commands or input should be allowed, and everything else should be denied. The Intrusion Prevention System (IPS) model of "deny some, allow everything else" will fail here.