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.