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.
