Sunday, February 8, 2015

ZigBee File Transfers and Advanced Fun Using Andrena


ZigBees are small, low cost, low powered wireless modules often seen in home automation applications. With their relatively low power consumption, and purported 1 mile range (line of sight using the PRO modules), their possible uses are only limited by your imagination. Configuration is simple, and as long as two modules are configured with the same channel, PAN ID, and encryption key (if in use), the modules will immediately sync up. Communication is generally serial, and you can easily setup a terminal attached to a ZigBee device and login remotely or send simple streams of data.


I needed some advanced features for a project that I have been working on.

  • Central Communication Handler (One to many)
  • Asynchronously deal with various agent modules
  • Additional layer of encryption
  • Support for multiple stream types
    • File Transfers
    • Announcements
    • Targeted Commands

This led me to developing my own protocol from scratch. The protocol, while not completely implemented already supports a Diffie Hellman key exchange between agents and the handler providing forward secrecy. File transfers currently work, and I will be adding features as I have time and require them.

The protocol

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|      Type     |   Stream Id   |      Flags    |     Length    |
|                             Seq Num                           |
|                               Tag                             |
|                             Payload...                        |

The tag is a four byte HMAC for the packet. Negotiations are HMACed with a pre shared key setup in the access control list between handler and agents. This helps mitigate the man in the middle threat. Yes, I know that a four byte HMAC and 4 byte unique counter is very small, and this was by design. The limitation of 98 bytes (plus 2 byte destination header) was the main consideration for this choice. The counter isn't as big of an issue, as you can always renegotiate a key once the possible list of IVs has been exhausted. This will be added in later releases.


The source is available on Github


This is still very much in the experimental phase. I have seen some people asking about file transfers with ZigBees, so I decided to publish the work that I have completed so far. If you see any outstanding issues with the crypto or code, please express your anger in the form of a pull request. Stay tuned on github for additional updates.

Wednesday, October 22, 2014

Your password doesn't suck, the server does


I read an article the other day that outlined the exact issue with passwords nowadays. Every website or application that requires a password always talks about the user creating a complex password. You know the routine:

    1 capital letter
    1 number
    1 special character
    no repeating characters

In this article I will outline why it's not your password that is insecure but rather admins not securing their code and/or servers well enough.

What complex passwords protect against

There are only two things a complex password actually helps protect against.

    Brute force attacks
    Dictionary attacks
Brute force attacks are pretty easily circumvented by adding a maximum password attempt before locking the account out. This is assuming that it is not an offline brute force attack, but we'll get to this later in the article. As for Dictionary attacks, that's easy circumvented by adding just an alpha/numeric into the password. So essentially a password as simple as password123 is a "secure" password; albeit it's something that could be easily guessed.

Offline brute force attacks

Offline brute force attacks are done by the attacker either having physical access to the server or the sever was not secure and the user was able to extract the password file. Which back to the title would tell me your password doesn't suck because the attacker should have never gotten to the point of getting the password file. Which leads me to my next point

Hybrid Attacks

Hybrid attacks complicate the "complex password" again by using standard dictionary attacks and adding numbers and symbols to them. And while this can take longer to crack, with the given technology even with a 15 character password can take less than an hour to crack offline.

Password Mangling attacks

If you've ever dealt with end users you know their passwords are very basic. Usually something simple that they add a number to the end, typically the current year or month. Password mangling is taking a dictionary attack, and adding rules to those lists. For instance adding a number to the end of basic password (i.e. - Summer to Summer14). Which can make cracking most typical user passwords very easy to crack. Again this can be circumvented by having strong server side security.


If servers are saving your password on the server in plaintext, there's absolutely zero reason to have a password. Which is a huge indication that the administrator has no idea what security is let alone how to use it.

End user problems

Saving your password on a piece of paper, or a text file. This is a no-no but with how many different passwords we need these days, and all have different requirements it's almost become impossible to remember all passwords. If there was more security on server side, there could be a standard for passwords that would make it easier to remember, especially if using common password for multiple websites/applications.

Other issues end users can face are a bit tougher to tackle such as spyware/malware/keyloggers. However going to back to server security we could see at least a 25% drop in drive-by malware/spyware if servers were more secure. While I'm a big advocate of "If it can be built it can be broken", I still believe we can get rid of at minimum 25%.

Virus definitions or signatures are what the anti-virus program looks at to determine if it's malicious piece of code or not. These definitions are so easy to get around based on how the programmer codes it. By reverse engineering and looking at both virus signature definitions and actual code of the virus we can easy stop more and more malicious software; albeit the more signatures there are the more false positives can be had as well.

Sever hardening

So what can be done server side to prevent having to have strong complex passwords?

Password attempt rules

Adding the security of locking out an account after x amount of failed password attempts fixes the issue with brute forcing the server. However it can't start and stop at the surface. There are many components especially server side that will need to be locked down the same. SQL server, Web App, Web Server root account, SSH, Telnet, etc. Anything that requires a log on for the server needs to be locked down with a lockout rule.

Default Accounts

This is one of my pet peves and something that is often over looked. Far to often a system gets compromised because of default username/password not being changed. I believe it was Target that was a victim of their SQL database being compromised due to default password being used on the server side. All default accounts should be disabled or removed and a new one created.


I could go into a lot more depth of how to properly secure a server but this article is not a how-to but rather an insight as to what common problems are with password security and why it's not your password that is horrible but instead the server and admins that are. Following best practices and learning basic server hardening can circumvent a lot of security breaches, and need for complex passwords.

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

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.