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.
