Droplets of Honey & The Modern Honeypot Network

Easy Setup

I’ve been meaning to play with honeypots for quite some time, and if I’d given it just a little more research, I’d have started much sooner. This is because shortly after deciding upon glastopf as the first on my list of honey pots  to try out, I came across mhn, an open source project by Threat Stream.

The Modern Honeypot Network (mhn) makes not only launching honeypots insanely easy, but it serves as a nice way of monitoring multiple honeypots as well. Digital Ocean Droplets  seemed like a cheap and safe way of getting started, and I quickly found this post by Lenny Zeltser which provides pretty good directions to anyone wanting to do this themselves.

My initial plan to create a single glastpof installation evolved into two more honeypots, one being dionea, and the other Wordpot.

Results So Far

After only 2 days of attacks there has certainly been a lot recorded, but I’ve not had the time to properly look into any of them yet. The Most prominent port for probes seems to be 5060, looking for phone system vulnerabilities I assume. Dionea has yet to capture any binaries, and Wordpot has been probed only 4 times.

I did do port scans on a few of the attacking IP Addresses and have seen a few older versions of Windows (2003, XP) with open VNC ports…

Open VNC Connection on Windows Server 2003

 

Further

With more time will come more data, and then the real fun begins.

The REST API included  in the MHN Framework makes sending the data to other applications simple. You can view the data for my honeypots over the Last 24 hours here.

For more information on the Modern Honey Network see Threat Stream’s blog post.

 

UPDATE 10/4/2016

I’ve stopped running my droplets recently. Other projects have taken up the bulk of my time and I no longer have the time to dedicate to monitoring them. The plugin I was using to connect this site and the Modern Honey Network Server can be found on my Github here

OWASP WordPress Vulnerability Scanner

WordPress makes up some large percentage of the web. As I’m writing this, web development firms all over the world are churning out WordPress sites for their clients. Some of these installs are vanilla and basic, yet some come with exceedingly complicated plugin/theme combinations. WordPress’ ease of use is a double edged sword. The positive side being a developer may complete a feature rich, member’s only website in one day. The negative being, a multitude of plugins and code snippets written by other developers are included in these projects (other wise they wouldn’t be completed within a day). A good developer will make good choices as to what plugins to use, a novice developer may not be able to tell, and things can become dangerous.

Vulnerabilities to WordPress itself are often handleable via automatic updates. If a client has brought an outdated site to your firm, often best practice is to back up the site in it’s current configuration, update it, and turn updates on from there on out. Plugins and themes can be harder to manage as far as security is concerned, given the nature of developers working on these projects for free, having their own lives, and maybe leaving these projects behind all together.

OWASP WordPress Vulnerability Scanner Project

The Vulnerability Scanner Project is a black box testing script for WordPress installations. A full description can be found on the projects OWASP Wiki.

The scanner is that of a php script checking a multitude of things that you’d otherwise have to check manually. It does this by reading various bits of the sites source to determine core version, theme information, and plugin information which it references with wpvulndb.com’s wordpress vulnerability database. Because this is a black box testing method, it alerts you to things that any visitor to your site may potentially discover. This differs from plugins such as Wordfence, which provide you with insider information (white box). I must disclaim by saying, a script such as this is a valuable tool for a developer to check client’s sites, or their own sites quickly for obvious problems, but keep in mind it’s far from a comprehensive security audit.

Source Code, Installation info, and information about contributing is provided via the WordPress Vulnerability Scanner Project’s GitHub.

Example Time

If you’re a debian user such as myself, you can get the dependencies for this with,
sudo apt-get install php5 php5-cli php5-curl php5-json git

Create a directory to store the wp-scanner code and navigate into it. Then clone the repo,

git clone https://github.com/RamadhanAmizudin/Wordpress-scanner.git

I went ahead to the WordPress Release Archives and downloaded version 4.1.6, which has known issues (just about every old version has issues). For this example, the site is installed on my local machine’s apache server in a directory titled /epm, and there are no other plugins or themes installed on the test site.

Usage of the WordPress Vulnerability Scanner is fairly simple, and for a list of all options just give the -h flag. The example below scans the url “localhost/epm” with the default settings as defined by the -d flag, and references its findings with the wpvulndb.com as defined by –wpvulndb.

php ./app.php -u localhost/epm -d --wpvulndb

The output for this is such,

+----------------------------------------------------+
|  __    __              _                           |
| / / /\ \ \___  _ __ __| |_ __  _ __ ___  ___ ___   |
| \ \/  \/ / _ \| '__/ _` | '_ \| '__/ _ \/ __/ __|  |
|  \  /\  / (_) | | | (_| | |_) | | |  __/\__ \__ \  |
|   \/  \/ \___/|_|  \__,_| .__/|_|  \___||___/___/  |
|                         |_|                        |
|                      Vulnerability Scanner v3.0.0  |
+----------------------------------------------------+
[+] Target: http://localhost/epm
[+] Start Time: 06-08-2015 02:03AM
[+] WordPress Version 4.1.6, using Meta Generator method

[+] Finding version vulnerability

[!] WordPress <= 4.2.3 - wp_untrash_post_comments SQL Injection 
[+] Fixed in version 3.8.10
[+] Reference:
[*]	http://wpvulndb.com/vulnerabilities/8126
[*]	https://github.com/WordPress/WordPress/commit/70128fe7605cb963a46815cf91b0a5934f70eff5
[*]	http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2213

[!] WordPress <= 4.2.3 - Timing Side Channel Attack
[+] Fixed in version 4.2.4
[+] Reference:
[*]	http://wpvulndb.com/vulnerabilities/8130
[*]	https://core.trac.wordpress.org/changeset/33536
[*]	http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5730

[!] WordPress <= 4.2.3 - Widgets Title Cross-Site Scripting (XSS)
[+] Fixed in version 3.8.10
[+] Reference:
[*]	http://wpvulndb.com/vulnerabilities/8131
[*]	https://core.trac.wordpress.org/changeset/33529
[*]	http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5732

[!] WordPress <= 4.2.3 - Nav Menu Title Cross-Site Scripting (XSS)
[+] Fixed in version 3.8.10
[+] Reference:
[*]	http://wpvulndb.com/vulnerabilities/8132
[*]	https://core.trac.wordpress.org/changeset/33541
[*]	http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5733

[!] WordPress <= 4.2.3 - Legacy Theme Preview Cross-Site Scripting (XSS)
[+] Fixed in version 3.8.10
[+] Reference:
[*]	http://wpvulndb.com/vulnerabilities/8133
[*]	https://core.trac.wordpress.org/changeset/33549
[*]	http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5734

[+] WordPress Readme file at http://localhost/epm/readme.html
[+] XML-RPC Interface available under http://localhost/epm/xmlrpc.php
[+] Full Path Disclosure (FPD) available at : http://localhost/epm/wp-includes/rss-functions.php
[+] Target is using twentyfifteen theme

[+] Finding theme vulnerability

[!] Twenty Fifteen Theme <= 1.1 - DOM Cross-Site Scripting (XSS)
[+] Fixed in version 1.2
[+] Reference:
[*]	http://wpvulndb.com/vulnerabilities/7965
[*]	https://blog.sucuri.net/2015/05/jetpack-and-twentyfifteen-vulnerable-to-dom-based-xss-millions-of-wordpress-websites-affected-millions-of-wordpress-websites-affected.html
[*]	http://packetstormsecurity.com/files/131802/
[*]	http://seclists.org/fulldisclosure/2015/May/41
[*]	http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3429

[+] Looking for visible plugins on homepage
[-] No plugin was found

[+] Finish Scan at 06-08-2015 02:03AM
[+] Total time taken is: 1 seconds

ryan@ryan:~/Desktop/Wordpress-scanner-master$ 

If this were to be a live site, there would be some obvious reasons to be worried.

Nexus 5 CM12 Setup Part 1

Within the same week, my girlfriend and I both found ourselves without phones. Her Galaxy took a soaking in the ladies room, and my late Nexus 5 had ceased to charge despite all repair effort. So now, I find myself with two fresh Nexus 5’s, a white for my girlfriend and a black one for myself, running Android Lolipop 5.0.1

I’m going to walk through the process of  what I’ve done setting up the devices. They are almost completely open source, with additional security and privacy features to be installed in Part 2. This is written as a fairly high level overview of the process, so I’ll try not to get into the nittygritty. This isn’t intended as a walk-through.

Since it had been a while since I played with my phone, I had to install some of the Android Developer Tools, adb and fastboot. In my case that meant a quick,

sudo apt-get install android-tools-adb
sudo apt-get install android-tools-fastboot

(thanks Debian)

In order to use these tools, usb debugging had to be enabled. Turning on developer mode had to be done first by navigating to,
Settings>>About Phone>>Build Number
I don’t know how many times, but by tapping the menu item rapidly, it will enable Developer Mode, and display “Developer Options” in Settings Menu. After that , USB Debugging needed to be checked for this process to continue.

With the phone turned on the following commands reboot the phone to the bootloader, and unlock it.
sudo adb reboot bootloader
sudo fastboot oem unlock

It’s that easy, gotta love Nexus devices for that.

Flashing the recovery was the next step. I’ve used both TWRP and CWM before. Initially, I attempted to flash TWRP, however it just wouldn’t stick, and would reboot to a stock recovery each flash. I tried a few versions (2.8.0.1 through 2.8.0.4). After researching various potential solutions, I bagged it and decided to flash CMW. This stuck the first time, download here. I don’t find myself in recovery that often, and I’m not married to either…whatever works. I went with the touch version which as of writing this is version 6.0.4.5.
Once more I rebooted the phone into the bootloader, and then flashed CWM to the Nexus 5 recovery partition.

sudo adb reboot bootloader

sudo fasboot flash recovery ./recovery-clockwork-touch-6.0.4.5-hammerhead.img

I chose to go with Cyanogen Mod. As of writing, this CM12 doesn’t have a stable build yet, and I’ve been flashing the nightlies every few days. The stability has actually been really good. The Nexus 5 is codenammed “Hammer Head” and releases of Cyanogen Mod can be found for it at https://download.cyanogenmod.org/?device=hammerhead
and the change log here http://www.cmxlog.com/12/hammerhead/

Flashing the Cyanogen Mod ROM went slightly differently for each phone. Both processes started with another reboot, this time to the newly flashed recovery partition. The caches are wiped in recovery, then

sudo adb reboot recovery
After the phones were in recovery, my girlfriends phone took the Cyanogen Mod zip file via adb push

sudo adb push ./cm-12-20150208-NIGHTLY-hammerhead.zip /sdcard

In the CWM recovery, I was able to install the zip from the sdcard. Oddly, my phone kept telling me the push was successful, yet the zip did not appear on my sdcard. This obstacle was overcome by installing the zip via an adb sideload

sudo adb sideload ./cm-12-20150124-NIGHTLY-hammerhead.zip

After a reboot, the phones were running CM12, however, they weren’t rooted. Booting back into recovery, the zip file for superuser must be placed in the file system.

sudo adb push ./UPDATE-SuperSU-v2.16.zip /sdcard

From there, it can be installed via the recovery. Downloading SU from the the Play Store (apk downloader), and the phone is rooted and ready for Part 2…coming soon