Wednesday, October 22, 2014

Your password doesn't suck, the server does

Outline

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
etc.

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.

Encryption

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.

Conclusion

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

Introduction

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 dht_sniff.py 51413
127.0.0.1:51413 -> 127.0.0.1:6969 (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

Defuse.ca's Encrypted Pastebin as a TOR Hidden Service

Introduction

The following is all based on the original code from defuse.ca 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.

Dependencies

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 DATABASE pastebin;
> 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 127.0.0.1:443
HiddenServicePort 80 127.0.0.1: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
sldfjadlkjfalieta.onion

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 server.key.org
 $ sudo openssl rsa -in server.key.org -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 127.0.0.1:80; ## listen for ipv4; this line is default and implied
  listen 127.0.0.1:443 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_pass 127.0.0.1:9000;
               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.

Testing

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

Introduction

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

$ 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 https://gist.githubusercontent.com/chokepoint/11305606/raw/52109f648c2ad5ec6a65bf8eee78fbda15fa1cfb/bcm43142_drivers.sh
$ chmod +x bcm43142_drivers.sh
$ sudo ./bcm43142_drivers.sh

Resources

Kali Linux
Broadcom Driver Instructions
Original wl_3.10 Patch

Script

#!/bin/bash
# chmod +x broadcom_drivers.sh
# ./broadcom_drivers.sh

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

if [ `uname -m` == "i686" ] ; then
 wget http://www.broadcom.com/docs/linux_sta/hybrid-v35-nodebug-pcoem-6_30_223_141.tar.gz
else
 wget http://www.broadcom.com/docs/linux_sta/hybrid-v35_64-nodebug-pcoem-6_30_223_141.tar.gz
fi
tar -xvf hybrid-v35*
wget http://www.mindwerks.net/wp-content/uploads/2013/10/wl_3.10.patch
patch -p2 < wl_3.10.patch
make
cp wl.ko /lib/modules/`uname -r`/kernel/net/wireless/
depmod
rmmod bcma
echo "blacklist bcma" >> /etc/modprobe.d/blacklist.conf
modprobe wl

Friday, February 14, 2014

Detecting Userland Preload Rootkits

Introduction

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/libc.so.6"

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/libselinux.so ./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 libdl.so'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 http://repo.crunchpwn.org/gnupg.key | sudo apt-key add -
$ echo '## Crunchpwn
deb http://repo.crunchpwn.org/ purson main' >> /etc/apt/sources.list
$ sudo apt-get update 
$ sudo apt-get install crunchpwn

Default Credentials

User: user
Password: crunchpwn

Screenshots




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.

DatePackageType
9-Feb-2014crunchpwn_0.1-7Full Alpha
9-Feb-2014cp-openbox-theme_0.1-2Update
6-Feb-2014exploit-db_02.06.2014Update
31-Jan-2014wifijammer_0.1New
31-Jan-2014crunchpwn_0.1-6Nightly Build
29-Jan-2014cp-openbox-themeUpdate
29-Jan-2014cp-slim-confUpdate
28-Jan-2014exploit-db_01.28.2014Update
25-Jan-2014crunchpwn_0.1-5Nightly Build
25-Jan-2014wolpertinger_0.6-1New
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.