Message-ID: <20040920001554.Y86687@dekadens.coredump.cx>
From: lcamtuf at ghettot.org (Michal Zalewski)
Subject: Tool announcement: fakebust

Good morning,

I am proud to announce the availability of fakebust 0.1 beta. 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.

The tool can be used to perform a quick and _meaningful_ assessment of
potentially rogue / fake 0-day exploit codes, trojans and backdoors (hence
Cc: to BUGTRAQ and Full-Disclosure), for carrying out a post-mortem
analysis of files recovered from a compromised system (FORENSICS), and for
performing a routine review of programs recovered from a honeypot setup
(hence HONETPOTS).

A working code and documentation can be obtained at:

   http://lcamtuf.coredump.cx/soft/fakebust.tgz

This is the initial public announcement, so expect the code to have some
silly bugs; your testing, off-list feedback, bug reports and comments are
welcome.

Below is a snippet from the README file, for those curious why they might
want to use the tool:

/.../

1) 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.

2) 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.

3) 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.

  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.

  Oh, right...

5) 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.

(...snip...)

For a full version of this write-up, including a discussion of technical
limitations of the approach, please check out the README file supplied
with the utility.

Powered by blists - more mailing lists