2014 Toolsmith Tool of the Year: SimpleRisk

Congratulations to Josh Sokol of SimpleRisk, LLC.
SimpleRisk is the 2014 Toolsmith Tool of the Year.
We mustered 933 total votes this year of which 438 went to SimpleRisk.
In Josh's own words, "I began writing SimpleRisk because I needed a tool to aide in my risk management activities and spreadsheets just weren't cutting it. But once I had a POC created, I knew that it was too good to keep to myself. I've always wanted to give back to the security community that has given so much to me. That's why I decided to release SimpleRisk under a Mozilla Public License 2.0. I hope it's as useful to you as it is for me."
Voters agree, SimpleRisk is definitely useful. :-)
Here's how the votes broke down.

Congratulations to all toolsmith entries and participants this year, and in particular to runners up Artillery from Dave Kennedy and Binary Defense Systems and ThreadFix from the Denim Group.
2015 promises us another great year of tools for information security practitioners and as always, if there are tools you'd like me to cover in toolsmith, please feel free to submit your favorites for consideration.

toolsmith: Kansa vs Operation Cleaver – PowerShell IR tactics

Prerequisites

Windows operating system with Windows Management Framework (includes PowerShell) 4.0. WMF 2.0 and 3.0 work but 4.0 is recommended.

Introduction

First of all, Happy New Year! I’m looking forward to a great 2015 and really appreciated your readership and support during the 2014 schedule.
I am both proud and humbled to announce that this is the ISSA Journal’s 100^th toolsmith, and 100 consecutive columns at that. It’s really hard to think back to October 2006 and imagine what toolsmith would become; it’s helped shape my career, my personal philosophy, and I believe it has contributed to the improvement of information security practices for numerous individuals and organizations. Nothing makes me happier than hearing from readers with success stories and wins using the numerous and invaluable tools we’ve discussed on these pages. To that end, I’m pleased to cover Kansa for this 100^th toolsmith. In his own words, Dave Hull’s Kansa is a modular framework for doing incident response (IR) data collection, analysis and remediation written in PowerShell that takes advantage of Windows Remote Management in order to scale up to thousands of systems. It evolved from a few PowerShell scripts that Dave had written for IR work. Through trial and error and some advice from Lee Holmes (@Lee_Holmes), Dave was able to convert those old scripts into a tool that relies on network logons using PowerShell’s default non-delegated Kerberos authentication. This ensures that the incident responder’s credentials aren’t as exposed to harvesting by common adversary tooling such as Mimikatz. This assumes one-hop scenarios (work station to server). In two-hop scenarios (workstation to server to server) the risk remains, as dictated by the necessity for CredSSP, where PowerShell performs a “Network Clear-text Logon”. Understand the risks and pitfalls and stick to one-hop scenarios easily supported by Kansa with its Target parameter, where you can run against numerous systems from a single list.

Per Dave, “Kansa is frequently used across enterprises to investigate thousands of systems relatively quickly. It can do lots of great things on its own, but also has the ability to push third-party binaries to remote hosts so more sophisticated tooling can be brought to bear – consider the Get-RekallPslist.ps1 module, that installs the WinPMem kernel mode driver on remote hosts and uses it to collect the list of running processes from a live system similar to the way Volatility does against a collected memory image, completely bypassing the Windows API. Because it’s written in PowerShell, extending existing modules or creating new ones is relatively easy and Kansa can even be used to clean up systems for tactical containment and remediation.”

Dave’s written his own excellent Kansa overview and usage guide for PowerShell Magazine, which is a true “must read” for you, do nothing else before doing so. We’ll take a more tactical, scenario-based approach to our use of Kansa here so as to provide a different perspective. To that end, Stuart McClure’s Cylance group recently published their Operation Cleaver (#OPCLEAVER) report, also a must-read, an in-depth study of an Iranian hacker collective’s tools, tactics, and procedures (TTPs). A number of indicators of compromise (IOCs) are included in the report, amongst which are included MD5 hashes for specific malware types including TinyZBot and Lagulon. As described in the report, there are numerous references to “cleaver” inside the namespaces of the collective’s custom code, including TinyZBot, thus the name Operation Cleaver. For the best reference material specific to TinyZBot in the report, see the Persistence section starting on page 47. We’ll focus on using Kansa to find one of the Lagulon keylogging samples.   

Tuning Kansa

Kansa is really meant for use across many systems, this one target scenario is a bit trite on my part. You’ll need to imagine the horsepower you see working for this one compromised host across hundreds or thousands of similarly buggered hosts.

On your target servers, script execution needs to be enabled for Kansa use. If you’re not familiar with Powershell, that’s as easy as:

1)      Right-click the Windows PowerShell shortcut.

2)      Select Run as administrator.

3)      Choose Yes when the UAC window appears.

4)      Use the Set-ExecutionPolicy cmdlet; enter and execute Set-ExecutionPolicy unrestricted.

5)      You’ll also want to run ls -r *.ps1 | Unblock-File to unblock the scripts.

You may also need to execute winrm quickconfig and/or Register-PSSessionConfiguration -Name Microsoft.PowerShell to overcome remote connection errors you may see written to the Kansa output directory if it can’t connect to the target host. You may also need to work around Windows firewall issues for PowerShell remoting if any of your network connection profiles are set to Public. You can run Get-NetConnectionProfile on Windows 8 or Server 2012 and later to see how your connections are configured then run the likes of Set-NetConnectionProfile -InterfaceIndex 25 -NetworkCategory Private to reset the culprit to Private. You’ll modify –InterfaceIndex to the correct number matching your Public connection(s).

You should have read Dave’s PowerShell Magazine article already but I will remind you that any binaries you may wish to utilize on target hosts, such as autoruns.exe or handle.exe from the Sysinternals collection, should be stored in the .\Modules\bin\ directory. Beware possible EULA issues with the Sysinternals tools. Even though the Kansa Get-Handle script passes handle.exe /accepteula –a, handle.exe hung on me in my test scenario.

A successful pre-infection Kansa run on my intended victim system, as spawned by .\kansa.ps1 -Target localhost -Pushbin –Verbose, is seen in Figure 1.

Figure 1 – Kansa test run

Kansa vs. Cleaver

I acquired a few samples as described in Cylance’s Operaration Cleaver report from @VXShare, as always, my favorite repository. After investigating the run-time behaviors of a few of them, I found a specific sample, a Lagulon variant, that was a good representative for Kansa use as it hit marks for a few of the IOCs mentioned in the report. The sample, MD5: 53230e7d5739091a6eb51298a50eb616, is discussed generally on page 58 in the report as part of the wndTest analysis, observed attempting to impersonate Adobe Report Service.

After executing the sample on my victim system (I had to pwn a real Windows image as the malware didn’t run in a VM environment) I re-ran Kansa and collected results from the Output directory. I then went on a subsequent search for all things Adobe related and uncovered more than a few IOCs. As all output files are TSV by default, they play nicely in Excel. The first hit came from the Get-Autorunsc module, the results from which I filtered by infection date to reduce the noise. The output as seen in Figure 2 shows that adbreport.exe has been configured to run at logon via C:\Users\malman\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup.

Figure 2 – Kansa uncovers an autorun entry

The next hit came from the Get-Handle module, the results from which I sorted alphabetically by Process Name to key on adbReport.exe. As you can see in Figure 3, adbReport.exe, as identified by Process ID 3396, has open handles on a number of files and registry entries.

Figure 3 – Kansa pivots on adbreport.exe handles

Note the \Device\KsecDD entry in Figure 3 as well, indicating direct device communication via the KsecDD driver.

More related IOCs were noted via the Get-ProcsWMI module which, per its own synopsis, “acquires various details about running processes, including command-line arguments, process start time, parent process ID and MD5 hash of the process image as found on disk”, the results of which you can see in Figure 4.

Figure 4 – Kansa closes the circle with the adbreport.exe MD5 hash

You’ve likely come to the conclusion that the hash referenced in Figure 4 is in fact that associated with the malicious binary acquired from VirusShare, thus closing the circle of discovery and incident enumeration with Kansa.

That said, again, single host scenarios with Kansa are cute, but it’s made to shine at scale. Viewing individual TSV files in Excel is definitely not a scale solution. How about viewing and parsing results via Log Parser? Better right? Integrate with SQL-based storage and you’re really off to the races. The Kansa Analysis folder includes a number of analysis-centric scripts to work with the results. They’re most often frequency analysis-oriented to work across a body of results from a plethora of hosts. Sadly my examples will only be from my one wee victim system, but you get the point.

 As an example in Analysis\Process you can use Get-HandleProcessOwnerStack.ps1 to pull frequency from all collected Get-Handle data based on Process Name and Owner. While I only collected one result set, .\Get-HandleProcessOwnerStack.ps1 | findstr "adbReport" tell me that adbReport.exe has 48 handles open as seen in Figure 5.

Figure 5 – Kansa frequency analysis across results

Had there been one or 1000 Get-Handle results in the working directory where Get-HandleProcessOwnerStack.ps1 was run from, it would count and sort ALL handles by process and owner.

If you need a frequency count of all instances of adbReport.exe via an MD5 hash match across all results from all hosts, you need only run Get-ProcsWMICLIMD5Stack.ps1. My favorite is sorting the same data set by creation date. This helps while conducting timeline analysis and will tell you when a process was created across all targets, the like of which is seen in Figure 6.

Figure 6 – Kansa determines creation dates across results

Response capabilities, analysis of the results, and even the premise of remediation via Kansa for the adventurous and innovative amongst you, all built into to one tidy PowerShell framework. For modern Windows environments, consider Kansa a must have in the IR toolkit.

In Conclusion

Come what may, in light of attacks as discussed in the Operation Cleaver report, tool frameworks such as Kansa help you leverage the real Windows workhorse that is PowerShell in order to better respond and analyze. Keep an eye on the Kansa Github site for updates and news and follow @davehull on Twitter. Dave and I also both follow @Lee_Holmes who we both consider to be the Don of the PowerShell family.

Remember to vote for your favorite tool of 2014, through January 15, 2015. I’ll announce a winner soon thereafter. Please vote and tell your friends and coworkers to do the same.

Ping me via email or Twitter if you have questions (russ at holisticinfosec dot org or @holisticinfosec).

Cheers…until next month.

Acknowledgements

Dave Hull (@davehull), Kansa developer and project lead

2014 Toolsmith Tool of the Year

If your browser doesn't support IFRAMEs, you can vote directly here.

toolsmith: Artillery

Prerequisites

Linux or Windows system with a Python interpreter

Introduction

I was reminded of Dave Kennedy’s Artillery while attending and presenting at DerbyCon 4.0 in September given that Dave is a DerbyCon founder. Artillery has recently benefitted from a major update and formal development support as part of Dave’s Binary Defense Systems (BDS) company. The BDS blog announced version 1.3 on November 11, which further prompted our discussion here. Artillery first surfaced for me as part of the ADHD project I covered during my C3CM discussion in October 2013’s toolsmith. While Dave’s investments in the security community have grown, Artillery was initially maintained by Dave’s TrustedSec organization then transitioned to BDS, given that group’s "defend, protect, secure" approach to managed security solutions. Artillery is an open source project created to provide early warning indicators for various attacks. Artillery was included in ADHD, the Active Defense Harbinger Distribution, because it spawns multiple ports on a system, a honeypot-like activity that creates “exposures” for attackers to go after. Dave described the fact that it also made blue teaming a bit easier for folks. Additional Artillery features include active file system change monitoring, detection of brute force attacks, and generation of other indicators of compromise. Artillery protects both Linux and Windows systems against attacks and can integrate with threat intelligence feeds allowing correlation and notification when an attacker IP address has previously been identified. Artillery supports multiple configurations, different versions of Linux, and can be deployed across multiple systems with centralized event collection. With a ton of support, and additions coming in from all over the world to make Artillery better, Dave mentioned that plans for Artillery include much better support for Windows, and expansion to allow a server/client model, moving away from purely standalone implementations. BSD’s plan is to continue significant development for Artillery while ensuring it maintains its open source origins allowing continued contribution back to the community Dave so readily embraces.

Laying In Artillery

Artillery installation is well documented on the Binary Defense Systems site and is remarkably straightforward. Note that I only installed and tested Artillery on a Linux system.

On the Linux system you wish to install Artillery, simply execute git clone https://github.com/trustedsec/artillery, change directory to the artillery directory just created, run sudo ./setup.py, then edit to the config file to suit your preferences. I’ll walk you through my configuration as a reference.

1)      I created a directory called holisticinfosec, and added “/holisticinfosec/” to MONITOR_FOLDERS

2)      I enabled HONEYPOT_BAN=ON, you’ll want to consider your implementation before you do this or you may inadvertently block legitimate traffic. You could also use WHITELIST_IP to prevent this issue and allow specific hosts but, as good as they are, whitelists can quickly become arduous to maintain. Bans and IPS-like blocks suffer from ye olde false positive issues when left unchecked.

3)      I used Yahoo for my SMTP settings (USERNAME, PASSWORD, ADDRESS) and set ALERT_USER_EMAIL to my holistincinfosec.org address for alert receipt. Caution here as well as you can quickly SPAM yourself or your Security Operations Center (SOC) monitored mail, and even cause an inbox DoS if your Artillery server(s) is busy. You can control frequency with EMAIL_TIMER and EMAIL_FREQUENCY, I suggest default settings initially (email alerts off) until you fine tune and optimize your Artillery implementation.

4)      Brute force attempts monitoring is cool and worthwhile, I enabled both SSH and FTP via SSH_BRUTE_MONITOR and FTP_BRUTE_MONITOR. Experiment with “attempts before you ban” as, again, you may not ban initially.

5)      The THREAT_INTELLIGENCE_FEED and THREAT_FEED allow you to consume the BDS Artillery Threat Intelligence Feed (ATIF). It’s represented as banlist.txt. You can pull from the BDS site or establish your own ATIF server for all you Artillery nodes to pull from. As with any blacklist, again, ensure that you want to block them all as there are more than 86,000 entries in this list. You can also add other lists if you wish as well.

6)      One of the most important settings are for your syslog preferences, you can log locally or write to a remote collector. This speaks to my defender’s sensibilities and we’ll discuss this further later as such.

The South Base Camp blog (@johnjakem) also has a nice writeup on Artillery nuances; it’s a quick read and worth your time.

Indirect Artillery Fire

I conducted basic tests of Artillery functionality with email alerts and banning enabled.

For the folder monitoring feature I wrote a file called test to the /holisticinfosec directory including the sentence “Monkey with me” and restarted Artillery. When I monkeyed with test by adding snarky commentary, I was alerted via email and a log entry in the local syslog file. Figure 1 is the email alert indicating the change to the test file.

Figure 1 – Artillery alert for change to test file

To blast the honeypot functionality, a nice Nmap scan sufficed with nmap -p 1-65535 -T4 -A -v -PE -PS22,25,80 -PA21,23,80,3389 192.168.220.130.

The result was an alert flood stating that [!] Artillery has detected an attack from the IP Address: 192.168.220.131 with example content as seen in Figure 2.

Figure 2 – Blocked and banned! Artillery stops attack traffic cold

I used Bruter to try and pound the FTP and SSH services but because the Artillery configuration was set to only four attempts before banning, my dictionary attacks were almost immediately kicked to the curb. Darn you, Artillery! For this experiment I enabled SYSLOG_TYPE=FILE in my Artillery configuration, which writes event to /var/artillery/logs/alerts.log instead of syslog.

Remember, if you find yourself unable to connect to your Artillery server on a specific port or aren’t writing test events, check your configuration file as you may have banned yourself. I did so more than once. Instantly solve this problem as follows: sudo ./remove_ban.py 192.168.220.1 where the IP address is that which you want to free from the bonds of iptables purgatory.

Direct Artillery Fire

Artillery represents a golden opportunity to harken back to my C3CM guidance, particularly Part 2, wherein I discussed use of the ELK stack, or Elasticsearch, Logstash, and Kibana. You can quickly set up the ELK stack up using numerous guides found via search engine and customize it for Artillery analysis.

Rather than repeat what I’ve already documented, I took a slightly different tack and utilized my trusty and beloved Security Onion VM. Doug Burks' (@dougburks) Security Onion includes ELSA (enterprise log search and analysis) which is a “centralized syslog framework built on Syslog-NG, MySQL, and Sphinx full-text search.” I could and should do a toolsmith on ELSA alone, but it’s so well documented by project developers and Doug, you’d do well just to read their content. To make use of ELSA I needed only point Artillery syslog to my Security Onion server by changing the /var/artillery/config file as follows:

1)      Changed SYSLOG_TYPE=LOCAL to SYSLOG_TYPE=REMOTE

2)      Set the IP address for my Security Onion server with SYSLOG_REMOTE_HOST="192.168.220.131"

3)      Restarted Artillery from /var/artillery with sudo ./restart_server.py

“That’s it?” you ask. Indeed. I logged into ELSA on my SO server after hammering the Artillery node with varied malfeasance, queried with host=192.168.220.130, you can see the results in Figure 3.

Figure 3 –Artillery events written to a remote Security Onion ELSA instance

ELSA provides you with a number of query options and filters so even if you have multiple Artillery servers you can zoom in on specific instances, dates, or attack types. A query such as host=192.168.220.130 groupby:program led me to program=”unknown” which, in turn, alerted me that I ended up being banned from Yahoo for spamming my account with alerts as seen in Figure 4.

Figure 4 – Artillery alerts me that I am a spammer

It’s always good to check your logs from a variety of perspectives. :-)

I intend to write some additional scripts for Artillery analysis and parsing, and devise additional means for incorporating threat intelligence to and from my Artillery instance. Let me know via the blog comment or Twitter how you’ve done the same.

In Conclusion

Artillery, on many levels, is the epitome of simplicity, which is part of why I love it. If you possess even the slightest modicum of Python understanding, the Artillery source files should make complete sense to you. Properly tuned, I can’t really think of a reason not to run Artillery on Linux servers for sure, and maybe Windows boxes where you have Python installed. Just remember to practice safe banning, you don’t want to drop production traffic. I’m really glad Dave’s Binary Defense Systems interest has taken over care and feeding for Artillery and can’t wait to see what’s next for this fine little defender’s delight.

It’s that time of year again! Be ready to vote for your favorite tool of 2014, I’ll soon post the survey to my website or blog and Tweet it out by mid-December. We’ll conclude voting by January 15, 2015 and announce a winner soon thereafter. Please vote and tell your friends and coworkers to do the same.

Ping me via email or Twitter if you have questions (russ at holisticinfosec dot org or @holisticinfosec).

Cheers…until next month.

Acknowledgements

Dave Kennedy (@HackingDave), TrustedSec, Binary Defense Systems, and DerbyCon

toolsmith: Inside and Outside the Wire with FruityWifi & WUDS

Prerequisites

I recommend a dedicated (non-VM) Kali distribution if you don’t have a Raspberry Pi.

Introduction

I have noted to myself, on more than one occasion, now more than eight years in to writing toolsmith, that I have not once covered wireless assessment tools. That constitutes a serious shortcoming on my part, one that I will rectify here with a discussion of FruityWifi and WUDS. These tools serve rather different purposes but both conform to the same principle of significant portability as both run on Raspberry Pi. Both also run on Debian systems (Kali) which is how I ran both for toolsmith testing purposes. FruityWifi is an open source platform with which to audit wireless networks, allowing users to conduct various attacks via the web interface or remote messaging. It is modular, feature-rich, and just celebrated a v2.0 release with many upgrades. WUDS, or the Wi-Fi User Detection System, on the other hand, is a proximity-based physical security concept that alerts on unapproved Wi-Fi probe requests bouncing off a WUDS sensor. Per the WUDS introduction, “The combination of a white list of unique identifiers for devices that belong in the area (MAC addresses) and signal strength (RSSI) can be used to create a protected zone. With tuning, this creates a circular detection barrier that, when crossed, can trigger any number of alert systems. WUDS includes an SMS alert module, but the sky is the limit.”

WUDS comes to us courtesy of toolsmith alum Tim Tomes (@lanmaster53) whose Recon-ng, the 2013 Toolsmith Tool of the Year, we covered in May 2013.

For FruityWifi highlights I reached out to xtr4nge (@FruityWifi), the project lead/developer.

The initial idea was to create an open source application to audit wireless networks and perform penetration tests from a Raspberry-Pi, or any other platform or device in a flexible, modular and portable manner.

Soon after the first version was published, FruityWifi was presented to a Rooted Warfare Spain audience (Rooted CON) in March 2014. FruityWifi was well received at the conference and by users from the onset, and many users sent feedback and ideas to improve it. 

A new version of FruityWifi (v2.0) was published a few weeks ago featuring many changes and updates; a new interface, new modules, Realtek chipsets support (confirmed in my testing with my Alfa card), Mobile Broadband (3G/4G) support, a new control panel, and more. The tool is under constant development and new modules and improvements are being published regularly.

Tim kindly provided detail regarding his favorite WUDS features and use case. His favorite feature is the alert system, and I strongly second this; I’ll show you why later in the article. Tim built a really simple interface for creating new alerts for the system, which does not require the need to dig into core components of the code to create new alerts. You need only add a function to the alerts.py file, name it correctly, and add associated options to the config.py file, and you’re finished. Tim’s script originally included just an SMS alerting mechanism, but he has since added a Pushover notification alert (5 minutes and 8 lines of code to implement); he exclusively uses the Pushover alert.

Tim’s favorite WUDS use case story is cited in his article, about the deliveryman alerting the system during testing. He’d been doing some testing the night before and in the middle of the afternoon the following day, an SMS message came through to his phone notifying him that someone had crossed his detection barrier. He was about to write it off as a false positive when the doorbell rang and it was a delivery service dropping off a package. The alert served as positive affirmation that the concept is a sound one.

In the future, Tim plans to either expand WUDS, or create another tool all together, that does the exact opposite of WUDS. Rather than alert on foreign MAC addresses, this tool would allow the user to configure the sensor to alert when certain MAC addresses leave the premises during specified windows of time. This would provide a sort of latchkey system that is not challenged by MAC randomization issues; devices will be properly connected to the local WAP with their normal MAC addresses when on premises. That said, the tool would need to be expanded to sense more than just probes.

I ran FruityWifi and WUDS on a dedicated Lenovo T61p laptop with Kali 64-bit installed and utilized the onboard wireless adapter.  Both tools are optimized to perform well on Raspberry Pi, but as I don’t have one, I experimented with both Ubuntu and Kali and was far more satisfied with Kali, no muss, no fuss. All installation steps that follow assume you’re running on Kali.

FruityWifi installation

FruityWifi installation is very simple. Download the master zip file or git clone the repository to your preferred directory, then cd /FruityWifi from there. Run ./install-FruityWifi.sh. If you have any issues after installation where FruityWifi isn’t available via the browser, it may be related to the Nginx/PHP5-FPM deployment. You can follow the FruityWifi Nginx wiki guidance to correct the issue. Thereafter, browse to http://localhost:8000 or https://localhost:8443, login with admin and admin (change the password), and you’re off to the races as seen in the UI’s configuration page per Figure 1.

Figure 1 – FruityWifi configuration page

FruityWifi inside the perimeter

Building on the same principles as the Pwn Plug, a FruityWifi-enable device can wreak havoc once unleashed inside any given network. There are a significant number of modules you can install and enable, a veritable fruit basket, depending on what you wish to accomplish, as seen in Figure 2.

Figure 2 – FruityWifi modules galore

If you utilized the earlier version of Fruity, you’ll really appreciate the update that is 2.0. Clean, fast, intuitive, and lots of fresh functionality. Red-teamers will enjoy AutoSSH, which allows reverse SSH connections, and automatic restart for connections that have been closed or dropped. FruityWifi 2.0 includes Nessus, Nmap, and Meterpreter as well. MDK3 is particularly attractive if you’re conducting an aggressive pentest and you want to create a distraction or a disruption.  You had better have permission before going off with MDK3, wireless hacking is deemed criminal in more than one state. MDK, or murder, death, kill for WLAN environments, utilizes a variety of SSID, authentication, and de-authentication flooding techniques to create wireless DoS conditions, and on occasion, WLAN hardware resets. My favorite recent addition to FruityWifi isn’t one of the hacking or enumeration tools, it’s actually vFeed from our friend @toolswatch. To quote vFeed’s description from the Fruity UI, is a vulnerability database (SQLite) that “provides extra structured detailed third-party references and technical characteristics for a CVE entry through an extensible XML schema.” You can search it right on your FruityWifi instance, after you’ve run Nmap and Nessus scans, identified potentially vulnerable targets and want to look up the related CVE. The available data includes:

• Open security standards: CVE, CWE, CPE, OVAL, CAPEC (all per Mitre), and CVSS
• Vulnerability Assessment & Exploitation IDs: Metasploit, Saint Corporation, Nessus Scripts, Nmap, Exploit-DB, milw0rm
• Vendors Security Alerts: Microsoft, Debian, Redhat, Ubuntu, and others

I looked up CVE-2013-3893, as seen in Figure 3, and was treated to a summary and exploit details. Take note of the vFeed export feature as well. I love vFeed so much I wrote an R parser to turn the XML export into human readable Excel docs for broad reporting and consumption without the machine layer. I’ll be sharing that via the HolisticInfoSec blog and website.

Figure 3 – FruityWifi’s vFeed module informs the analyst

FruityWifi represents a fabulous way to establish a foothold inside a given perimeter, pivot to additional targets, and conduct complete compromise. Let’s now explore WUDS, intended to help you defend the perimeter. First a little red, then a little blue. Wi-fi not?

WUDS Installation

Tim’s Bitbucket installation guidance is short and sweet:

sudo apt-get install iw python-pcapy sqlite3 screen

# launch a screen session

screen

# install WUDS

git clone https://LaNMaSteR53@bitbucket.org/LaNMaSteR53/wuds.git

cd wuds

# edit the config file

leafpad config.py

# execute the included run script

./run.sh

You really need to get your config.py implementation correct. Default settings work well initially until you get to your ALERT_SMS CONFIG. You’ll need SMTP server access, including the outgoing SMTP server with the TLS port along with username and password, in order to send alert messages. Android and iOS users (there are browser plugins too) can also take advantage of a Pushover account, as Tim mentioned.

Debug is enabled by default, if there are issues, when you run ./run.sh you’ll receive failure notice.

WUDS defends the perimeter

Once WUDS is running there’s not a whole lot to actually see. No sexy UI, just a SQLite database and alerts of your choosing. Figure 4 represents a sqlite browser view of logs.db the WUDS datastore.

Figure 4 – A view to the WUDS database

You’ll note that the detected devices all have received signal strength indications (RSSI) of higher than -50. Recall, how much I stressed config.py. The default RSSI threshold for triggering alerts is -50, but you can adjust it depending on how you wish to define your perimeter.  

The real pleasure comes from the first alerts received on your mobile device. As you see in a screen shot from my phone (Figure 5), proximity alerts advise me that a variety of devices have been detected on the premises. Ruh-roh!

Figure 5 –WUDS alerts of perimeter violations

True story. When I first enabled WUDS in my office at work, I immediately received alerts for an HP device that was beaconing for my home wireless AP. This freaked me out for a minute as I knew of no HP devices currently in use and certainly not those looking for my house infrastructure. After looking around again, and calming down a bit, a spotted it, an old HP printer under my desk that I’d brought in for scanning, had turned it on years ago, and literally forgotten about it ever since. And there it was, blindly beaconing away for a WAP it would never again communicate with. Thanks WUDS!

You’ll find all sorts of interesting devices chattering away when you enable WUDS. Just remember, the more dense the population area, the noisier it will be. Avoid self-induced mobile device DoS attacks. :-)

In Conclusion

Great tools from xtr4nge and Tim, I’m thrilled to have gotten off the schnide regarding wireless topics with FruityWifi and WUDS. I’m thinking there’s actually an opportunity to incorporate WUDS in FruityWifi. You heard it here first. Enjoy these tools, they’re both a ton of fun and incredibly useful at the same time.

Ping me via email if you have questions (russ at holisticinfosec dot org).

Cheers…until next month.

Acknowledgements

xtr4nge, FruityWifi project lead and developer

Tim Tomes, WUDS project lead and developer