1 / 17

Interception and Analysis Framework for Win32 Scripts

This document outlines a robust framework developed for the interception and analysis of malicious Win32 scripts. It examines the background and preliminary characterization of threats posed by active scripting languages such as JScript and VBScript. The framework enables effective policy development and enforcement, balancing legitimate use with malicious activities. The architecture supports extensive logging of script behavior to a remote server, allowing for improved monitoring and control of script-based threats on Microsoft Windows platforms, addressing gaps in existing commercial defenses.

gail-lane
Télécharger la présentation

Interception and Analysis Framework for Win32 Scripts

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Tim Hollebeek, Ph.D. tim@cigital.com Interception and Analysis Framework for Win32 Scripts www.cigital.com (not for public release)

  2. Overview • Background • Preliminary characterization of attacks/threats • What we’ve built • Coverage of threats • Tech Transfer successes • Integration

  3. Background: ActiveScripting • Microsoft architecture for integrating scripts with applications in a language-neutral way. • Scripting is often used as “Turing glue” to connect and drive disparate software components. Active Scripting Languages • Perl • Jscript • VBscript/VBA (macros) • Rexx • Python Active Scripting Applications/Hosts • Web browsers • Mail readers • Embedded HTML viewers • MS Office 2000 applications • Windows Scripting Host

  4. Technical Objectives • Address the threat of a significant class of mobile malicious code: • ActiveScripting (JScript, VBscript) • Provide interception and logging framework that allows policies to be developed and enforced • Constrain active scripting capability effectively to balance: • legitimate uses vs. malicious uses

  5. Scope • Malicious Scripts on Microsoft Windows based platforms • Script-based viruses, trojans • malicious web pages • malicious HTML embedded in various files • Especially: scripts that use one of about 30 vulnerabilities that allow compromise of the machine from scripts (most recent … 9 days ago)

  6. Attacker Objectives • Traditional “malware” activities • Viruses, trojan horses • Fully compromising host computers • Accessing sensitive data/manipulating sensitive functionality • Compromising script-aware applications • Compromising script-dependent applications

  7. Why is this easy? • MS Windows contains lots of bad code and very few boundaries • Microsoft architecture is script-friendly • “big bag of components” • Much of this infrastructure built to support distributed applications

  8. Defenses • Must be at the correct level (or multi-level) • Most existing defenses aren’t: • Secure sessions • Filtering • Signature schemes • Kernel/filesystem level defenses • Commercial world focused on today’s attacks

  9. Categories of Malicious Scripts Easy • Malicious scripts distributed as attachments • Embedded scripts that exploit flaws in components or host applications • Malicious scripts that manipulate legitimate functionality Hard • Malicious scripts injected into dynamic web pages • Scripts that exploit the distributed nature of web applications Very Hard!

  10. Malicious Script Capability Matrix Web based Attach Flaw Legitimate Inject ILOVEYOU Kak Malicious web site E*TRADE hack E-bayla Web bugs E-mail wiretapping Future threats

  11. Intercepting ActiveScripting • What works well: • Blocking access to flawed components/methods • Feasible: • Correlating script activity with lower level information • Reducing exposure of script-aware applications • Restricting script actions to safer subset • Still difficult: • Script-dependent and script-based applications

  12. Tech Transfer • Produced: • Robust prototype • Capable of extensive logging of script behavior on a number of machines to a remote server • Ability to block malicious script actions • Stable, efficient • Developing prototype into a tool to be used by Air Force community • Extensive logs (14,000 distinct scripts, gigabytes of information about their execution) • JustBeFriends (~4000 downloads)

  13. Integration • We can provide: • Information on all page views • Script contents and URLs • Information on script behavior • During script execution: • Accesses to all members and methods (with parameters) of Automation objects the scripting engine interacts with • All actions of the scripting engine • Other related COM methods (possibly) user level correlation information

  14. Logs • 3 Cigital Labs researchers • 6-12 months of browsing • Work-related and “other” sites • Also some “random” browsing (uses Yahoo!)

  15. Architecture Centralized Logging Server XML Policy Script Actions Event Manager Scripting Engine Events Browser Architecture

  16. Conclusions • Architecture provides a very successful and flexible way to monitor and control scripts on Windows systems • Can address commonly exploited risks from malicious scripts, which are unaddressed by current generation of commercial tools • Work still needed to get a handle on more complex attacks

  17. END • The End

More Related