[TOOL] Fakebust - Fake Exploit Code Detector

From: SecuriTeam (support_at_securiteam.com)
Date: 10/05/04

  • Next message: SecuriTeam: "[NEWS] Default Username/Password Pairs in ON Command CCM 5.x Database Backend" 
    To: list@securiteam.com
Date: 5 Oct 2004 12:20:33 +0200

    The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
    - - promotion

    The SecuriTeam alerts list - Free, Accurate, Independent.

    Get your security news from a reliable source.
    http://www.securiteam.com/mailinglist.html

    - - - - - - - - -

      Fakebust - Fake Exploit Code Detector
    ------------------------------------------------------------------------

    SUMMARY

    DETAILS

    Fakebust is a simple, open-source, user-friendly, intuitive and very rapid
    malicious code analyzer that can partly replace and in certain aspects
    outperform an expensive, strictly controlled sandbox setup.

    What does this program do?
    Fakebust is a tool for system administrators and security professionals
    and amateurs alike. It is a simple, specialized detector of malicious
    code, specifically tailored to speed up examination of purported exploits
    and other simple tools of unknown or untrusted origin, or unidentified
    binaries recovered during forensics of compromised accounts or machines.

    Why knowing is important?
    Security professionals and administrators often have to deal with C
    sources or binaries recovered from Usenet groups, mailing lists, various
    web forums, IRC channels, or simply encountered on one of their own
    machines, particularly on multiuser shell systems. Such programs often
    claim to perform certain tasks, but may very well carry malicious payload
    instead (or be capable of both).

    Depending on the real payload of a program, different routes may have to
    be taken upon program's discovery - and often, every hour counts. For
    example, if a binary claiming to be a 0-day exploit for Apache is
    obtained, and proves to be legitimate, immediate workarounds need to be
    implemented across the enterprise, and systems must be checked for
    compromise symptoms immediately. The only fast way to find out whether it
    indeed works is to execute it - but if it turns out to be a Trojan horse,
    the callee will be in trouble, and will have to invest time and effort to
    assess and repair damage.

    Why telling is difficult?
    In recent years, there is a steady increase in the number of fake
    exploits, trojaned tools, and other Linux malware. Although as soon as
    sources are present, trivial trickery is easy to spot to a person with C
    language skills, some recent examples of programs that use subtle
    overflows, confusing naming and pointer arithmetic, or other IOCCC-grade
    tricks may escape even most experienced programmers, and become apparent
    only after a careful line-by-line analysis or single-stepping the program
    under a debugger. Those tasks are not within the skillset of all system
    administrators, and remain far too time-consuming to be used routinely -
    not to mention, sometimes sources are nowhere to be found, and binaries
    are additionally obfuscated to make analysis more problematic.

    As a result, a good number of sysadmins either panic and never examine
    suspicious code at all, often not learning about problems they may have;
    others would run the code, only to sooner or later fall prey to attackers,
    or at least suffer the ultimate humiliation of having their /etc/passwd
    and /etc/shadow mailed to an address in People's Republic of China.

    Why checking is problematic?
    A common practice among the more enlightened crowd is to roll out a test
    system, or a virtual machine under Bochs, VMWare or other emulator, and
    then to run the code in such a "sandbox". The assumption is that the
    sandbox can be brought down and reinstalled at will, hence it does not
    matter if it gets compromised or backdoored; and that giving access to
    data and network context of the box to a rogue entity for a short period
    of time will not pose a significant threat.

    This is a fancy and imperfect solution, however. Not only it requires
    additional equipment or resources, ideally restored to virgin state before
    and after every test, but it remains time consuming to conclusively assess
    all "side effects" of code execution. Not many users can afford to run a
    sandbox, and even fewer has the expertise and time needed to determine
    what happened inside.

    What fakebust can do to help?
    Fakebust is there to provide an ugly but viable compromise between
    extensive analysis and blind execution. It is an interactive "bounding
    box" debugger, under which the program is allowed to run for as long as
    certain boundary I/O conditions are not violated. Whenever the program
    attempts to gain access to a new, security-relevant resource, or tries to
    otherwise extend its permissions to a degree that would affect the system,
    the code is stopped, and the user is presented with an informative
    description and a choice what to do next. Typical choices are:

     - Deny the request and abort the program - typically picked as soon as
    you conclude it is malicious,

     - Permit the program to perform action once - picked once the request is
    deemed to be justified, and the resource does not yield any undesirable
    information,

     - Permit this and future access of this type to this resource - when
    accesses to a file or connections to a host are expected to recur,

     - Deny the request, but do not abort the program; the syscall will not
    execute, and a value closest to "success" will be passed back to the
    program as a simulated result. A good option whenever it is apparent that
    the program is misbehaving, but it is not clear yet what its goal is.

    In other words, under fakebust, you can finally run the elusive Apache
    0-day exploit and be automatically warned if it attempts to execute
    shellcode locally rather than remotely, or attempts to dial a host in
    China with your /etc/passwd in hand; or attempts to write to
    /etc/ld.so.preload; fiddles with /dev/kmem, etc. You will be able to stop
    an undesirable action before it is carried out.

    Under this tool, you can safely test and meaningfully supervise
    potentially malicious code without having to build a fully-blown sandbox,
    and without having any ninja skills or a passion for Russian roulette.

    IMPORTANT NOTE:
    In case of exploits that are very much legitimate, but have a malicious
    payload (for example, after successfully exploiting SSHD on the remote
    host, they send a shellcode with "rm -rf /" payload), fakebust can and
    should be also attached to the target of an attack to control the other
    end (with the --pid command-line option).

    Is it insanely complex and insecure?
    Fakebust simply monitors all syscalls invoked by a program, and ignores
    some harmless ones, while commenting and prompting on others. You are
    provided with a clear description of the operation, its possible reason,
    and basic information about parameters to the syscall.

    There are four basic operating modes: "local exploit" (--local), which is
    tailored for analyzing local privilege elevation exploits and other
    generic command-line utilities (as an unprivileged user); "remote exploit"
    (--remote), which is optimized for network-based TCP or UDP attacks and
    other network tools that do not require root privileges; "raw socket"
    (--rawsock), which is similar to "remote exploit", but assumes the program
    requires root privileges, presumably to send hand-crafted IP packets; and
    finally, "process attach" mode (--pid), in which the program attaches to a
    running prospective victim of an exploit to examine whether any malicious
    code is being executed by the shellcode.

    These settings mostly affect the commentary provided with every
    questionable syscall, and the default option in every menu; the actual
    level of protection offered by fakebust is the same in every mode.

    Hence, although it may appear to be an abstract and high-level analyzer,
    the tool is simple as a brick, and rather fool-proof. It should not be
    easy to bypass or confuse (but do not run it on your company's primary
    financial processing mainframe if you do not have backups, ok?). You
    should be very much safe running malicious code on your workstation under
    fakebust.

    It is still prudent to have backups and use common sense, as almost all
    non-trivial programs have flaws, and I will not bet my life on this one
    being a rare exception to the rule; besides, you may simply make a mistake
    at some point, and press the wrong button approving execution of "rm -rf
    /"... or accidentally execute a program outside of fakebust.

    Why does this program suck?
    Fakebust is NOT a definitive answer to all problems, of course. Its major
    limitations (aka "suction points") are:

    1) Certain particularly naughty programs may deploy generic debugger
    evasion tactics and refuse to work under a debugger like this. Due to the
    shortcomings of Linux debugger API, this is actually painfully trivial to
    achieve. If you have a reason to suspect this is the case, you should
    approach the code with prejudice and examine it manually, or ask an expert
    for help.

    2) Not all programs should be traced under fakebust. Complex applications
    that perform massive filesystem or network I/O may trigger so many alerts
    it becomes impractical or at least quite annoying to use this utility.
    Most exploits and other simple tools do not fall in this category,
    however. If you encounter excessive number of alerts in a simple program,
    be careful.

    3) Fakebust will not work particularly well against exploits written in
    heavyweight interpreted languages (bash, Perl, Python), because there is
    an extreme syscall-level overhead of the interpreter itself. If the
    interpreter opens hundreds of files before even starting to process the
    main program, it may be painful to step through this part.

    NOTE: The utility CAN be tailored to work well with those languages by
    making several minor tweaks and altering the list of "safe" files in
    config.h). If you want to help out, let me know.

    When it comes to compiled code, fakebust does not discriminate against
    languages or linking modes. C, Assembler, Pascal, Ada, etc are all
    acceptable.

    4) The tracer does not support threads and multiple child processes.
    Tracing threads through the Linux debugger API is generally rather
    problematic. With child processes and threads, there are important shared
    memory / concurrency problems that need to be addressed.

    At current, whenever fork() or vfork() is encountered, you may choose to
    either continue tracing the child process (and terminate the parent), or
    continue tracing the parent (without spawning a child); clone() call is
    not tolerated.

    5) If you expect an exploit to be legitimate but have a remotely implanted
    malicious payload (such as an exploit invoking "rm -rf /" on a remote
    system), you need to deploy a second instance of fakebust on the side of
    the victim process, or risk trouble. You can attach to a running process
    by using --pid command line option.

    6) You are advised to use kernel without the experimental "mapped I/O"
    networking feature. This way, you will be able to examine all outgoing and
    incoming packets on raw sockets without the risk of missing any data.
    Otherwise, there will be a way to bypass monitoring on raw sockets.

    7) Whether the name of the tool should stand for "fake (exploit) buster"
    or "fake (woman's) bosom" is up to the user.

    ADDITIONAL INFORMATION

    The information has been provided by <mailto:lcamtuf@ghettot.org> Michal
    Zalewski.
    The tool can be downloaded from: <http://lcamtuf.coredump.cx/soft/>
    http://lcamtuf.coredump.cx/soft/

    ========================================

    This bulletin is sent to members of the SecuriTeam mailing list.
    To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

    DISCLAIMER:
    The information in this bulletin is provided "AS IS" without warranty of any kind.
    In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

  • Next message: SecuriTeam: "[NEWS] Default Username/Password Pairs in ON Command CCM 5.x Database Backend"

    Relevant Pages