toolsmith: EMET 4.0 - These Aren’t the Exploits You’re Looking For

Prerequisites

Windows operating system

.NET Framework 4.0 or higher

Introduction

In classic Star Wars parlance, have you been looking for improved tactics with which to wave off grievous Windows client exploits? Look no further; Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) 4.0 was released to the public on 17 JUN 2013 and quickly caught the attention of security aficionados and general press alike. KrebsOnSecurity even gave EMET full coverage and as always Brian’s quality work is well worth a read for the 101 perspective on EMET 4.0. So much of the basic usage, configuration, and feature set has already been covered or introduced that I’m going to simply refer you to the Kreb’s post as well as Gerardo Di Giacomo’s ThreatMitigation with EMET 4.0 as prerequisite reading material. I work with Gerardo at Microsoft and as with all toolsmith’s I sought insight on the tool in question. As his Threat Mitigation post had just gone live as we talked, I will simply draw a quick summary from there; you can read the rest for yourself. EMET is a “free utility that helps prevent memory corruption vulnerabilities in software from being successfully exploited for code execution. It does so by opting in software to the latest security mitigation techniques. The result is that a wide variety of software is made significantly more resistant to exploitation – even against zero day vulnerabilities and vulnerabilities for which an update is not available or has not yet been applied. EMET offers protections for all currently supported Microsoft Windows operating systems, and supports enterprise deployment, configuration, and monitoring.” I will give you the quick bullet list of features but will move quickly to what exploitation mitigations EMET 4.0 offers when tossing attacks via Metasploit against a protected system and applications. Following are feature highlights for EMET 4.0:

·         Certificate Trust: Detect Man in the Middle (MITM) attacks that leverage fraudulent SSL certificates

·         ROP mitigations: Block exploits that utilize Return Oriented Programming exploitation techniques.

·         Early Warning Program: Allows enterprise customers and Microsoft to analyze the details of an attack and respond effectively.

·         Audit Mode: Provides monitoring functionalities for testing purposes.

·         Redesigned User Interface: Streamlined configuration and improved accessibility.

Of note, the Early Warning Program sends information back to Microsoft. If yours is an organization that already does this via other enterprise means, this is already common place behavior, but if your preference is to keep such data in house you can disable Early Warning under the Reporting menu or use System Center Agentless monitoring to forward the telemetry data to an on-premise server that can be later used for forensics or post-mortem. In production environments, you may want to make use of Audit Mode before setting EMET to terminate programs when attacked. Audit Mode instead simply reports the exploitation attempt; helpful for monitoring potential compatibility issues between EMET and protected applications.

  

Installing EMET 4.0

Installing EMET is point-and-click simple. Just download, ensure you have .NET Framework 4.0 or higher installed, accept installation defaults (Use Recommended Settings), and you’re off to the races.

The EMET 4.0 User’s Guide included on the download page is a required read as well. I ran EMET 4.0 on a Windows 7 SP1 Enterprise 32bit VM with .NET Framework 4.0, Java 1.7.0_25, and Firefox 22 (really?).

For testing, enabled the Maximum security settings under Quick Profiles. This sets Data Execution Prevention (DEP) to Always On and Structured Exception Handler Overwrite Protection (SEHOP) to Application Opt Out as seen in Figure 1.

FIGURE 1: EMET deployed and ready

That said, on production systems, take baby steps. You can begin to add other applications than those protected by default (Internet Explorer, Java, Wordpad, Adobe Reader, Microsoft Office, etc.) but as mentioned above and in Kreb’s article, phase apps in to ensure they don’t struggle or crash with the added protection and “avoid the temptation to make system-wide changes.”

EMET 4.0 Mitigations and Blocked Attacks

First up, ye olde heap spray attack. Via Metasploit on my Kali Linux VM, I queued up the Microsoft Internet Explorer Fixed Table Col Span Heap Overflow (MS12-037) module. This module “exploits a heap overflow vulnerability in Internet Explorer caused by an incorrect handling of the span attribute for col elements from a fixed table, when they are modified dynamically by JavaScript code” and utilizes ROP chains as part of the attack. Drawing right from Rapid 7, as they describe heap spray techniques for Metasploit browser exploitation, a heap spray is a way to manipulate memory by controlling heap allocations and placing arbitrary code in a predictable place.  This allows the attacker, when controlling the crash, to trick a program into going to said predictable place and gain code execution. Figure 2 represents the attempted delivery of such an attack via MSF.

FIGURE 2: MS12-037 IE Col Span attack

On the Windows 7 VM, when browsing to my attacker server, http://192.168.220.145:8080/JwJKD1Sjq, via Internet Explorer, EMET immediately responded with an application mitigation, shut down IE and popped a Tray Icon notification as seen in Figure 3.

FIGURE 3: EMET blocks HeapSpray attack

Given that EMET also writes events to the Windows Application Event Log, enterprises are afforded an additional monitoring opportunity as a result. No matter your Windows event collection mechanism, be it Windows Event Collector, Audit Collection Services (ACS), OSSEC, Snare and Splunk, or your preferred method, you can add an alerting mechanism (you may be feeding a SIEM) to give you a heads up when a client machine triggers an EMET event. Regardless, Figure 4 represents the Event Viewer perspective on our attack from Figure 2.

FIGURE 4: EMET event in Event Viewer

Another example includes the Mandatory ASLR mitigation. Address space layout randomization (ASLR) randomly arranges the positions of key data areas, to include the base of the executable, as well as position of libraries, heap, and stack, in a process's address space. Note that, as indicated in the EMET User’s Guide, EMET’s mitigations only become active after the address space for the core process and the static dependencies has been set up. Mandatory ASLR does not force address space randomization on any of these. Instead, Mandatory ASLR is intended to protect dynamically linked modules, such as plug-ins. When I browsed my Metasploit instance configured with the Internet Explorer CSS Recursive Import Use After Free module (MS11-003) enabled Internet Explorer was again terminated as seen in Figure 5. 

FIGURE 5: EMET Mandatory ASLR notification

Last but not least, I tested the Certificate Trust (Pinning) feature by manipulating the pinned certificates for login.live.com. EMET 4.0 protects the likes of Live, Yahoo, Skype, Twitter, Facebook and Office 365 by adding extra checks during the certificate chain trust validation process, with the goal to detect man-in-the-middle attacks over an encrypted channel. By default, EMET pins the certificate for a website to the good, trusted Root CA certificate; login.live.com is pinned to Baltimore CyberTrust Root, Verisign, GlobalSign Root CA, and GTE CyberTrust Global Root, as these are the Root CA certificates that are expected to have issued a certificate for login.live.com. I arbitrarily removed these and imported a Thawte Windows Trusted Root Certificate (trusted by Windows). This resulted in EMET sounding off with another “I don’t think so” as seen in Figure 6.

FIGURE 6: EMET trusts you not

As Thawte is clearly not the Root CA that issued the certificate for login.live.com, EMET flagged the SSL cert. By pinning the right certificates’ websites to their expected Root CA certificates, you can detect scenarios where a certificate is fraudulently issued from a compromised Root CA or one of its intermediates.

For you command line fans, you can choose to utilize EMET_Conf.exe. You’ll need to set C:\Program Files\EMET 4.0 in your PATH statement if you wish to call EMET_Conf.exe from any prompt. EMET_Conf.exe allows you to add applications, list those already added, list enabled mitigations and trusts, as well as remove, modify, import/export, and configure.

Remember, for those of you with enterprise deployment responsibilities, EMET can be deployed and configure with System Center Configuration Manager (SCCM), and EMET system and application mitigation settings can be configured via Group Policy.

In Conclusion

The release of version 4.0 brings EMET squarely in sight for users who may have been hesitant to utilize or deploy it. Now’s the time to investigate and engage (wait, that’s Star Trek). EMET 4.0 adds a layer of protection that friend, and EMET’s #1 fan, TJ O’Connor refers to as “creativity in defense”; I'll give him the closing comments:

"All too often the balance of creativity favors the attacker. Attackers overcome difficult exploit mitigation strategies by hurdling over them with creative attack strategies. Attackers have succeeded with creative techniques like heap-spraying, ROP Gadgets, SEH Overwrites, or ASLR partial over-writes. EMET 4.0 returns the balance of creativity to the defender. Instead of looking for fixed known signatures of attack, EMET 4.0 looks for the adversary trying to hurdle over the mitigation strategy. Because of this, EMET can identify a novel attack and stop it without previous knowledge of the attack. Its the most overlooked game changer in a defense strategy." 

Remember, test and tune before going full tilt boogie but know that EMET adds defense-in-depth for one host or an entire enterprise, even in the face of 0-days.

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

Cheers…until next month.

Acknowledgements

Gerardo Di Giacomo, Security Program Manager, Microsoft Security Response Center (MSRC) Software Security Incident Response team

toolsmith: Visual Malware Analysis with ProcDOT

 

Prerequisites/dependencies

Process Monitor

GraphViz

Windows or Linux operating system

Introduction

As I write this I’m sitting in the relative darkness of the HolisticInfoSec lab listening to Random Access Memories, the new release from Daft Punk, and literally freaking out over what Time magazine’s Jesse Dorris has glowingly referred to as a “sound for which the word epic seems to have been invented.” Follow me as I step way out on a limb and borrow from Dorris’ fine review to create a musical allegory for this month’s topic, ProcDOT. Dorris describes a “world in which the bounties of the past, present and future have been Tumblr’d together into a stunning data blur.”[1] I will attempt to make this connection with what ProcDOT’s author, CERT.at’s Christian Wojner, refers to as “an absolute must have tool for everyone's lab.” This is a righteous truth, dear reader; those malware analysts amongst you will feast on the scrumptious visual delight that ProcDOT creates.

We’ve not discussed visualization tactics in quite a while (March 2010) but read on, the wait will be justified. ProcDOT, as described in Christian’s March 2013 blog post, correlates Windows Sysinternals Process Monitor log files and PCAPs to an investigation-ready interactive graph that includes the animation of a malware infection evolution based on activity timelines.

Christian gave me the full picture of his work creating ProcDOT to be shared with you here.

ProcDOT is the result of two ideas Christian had over the last few years. Initially he was thinking about the benefits of correlating Process Monitor logs with PCAP data to simple line charts with time and peaks as well as the ability to define tags for specific data situations. Sometime later, at the end of a malware investigation for a customer, he came to the point where he wanted to explain the characteristics of the underlying infection and depict the interaction of the malware's components as part of his final report. Christian found that a simple verbal description was both massively inefficient and insufficient at the same time (I confirm this shortcoming as well). Christian’s thinking moved to the “big picture” in terms of a graph with nodes for the relevant objects as files, registry keys, etc. and edges for actions between them.

He then took the time to experiment with the Process Monitor logs he’d captured while trying to strip them down to the relevant content. This content he then manually converted to fit the input format of AT&T’s Graphviz as chosen as a renderer for graphing. And there it was; a picture can tell a thousand words. It immediately became easy to understand all the aspects of the infection in one glance, even without any verbal explanation. That said, the manual activities to get to this result took about 50% of Christian’s time during report generation and he had not yet included PCAP data at this point.

As the high potential of this approach proved itself obvious, Christian started to think about a tool that might take advantage of all this potential while bringing behavioral analysis a step further and making it accessible to non-malware analysts. Thus was born the ProcDOT project.

As ProcDOT is now close to its first official release it is actually possible to automatically generate such a graph within seconds while also considering the information in an optionally supplied PCAP file correlating them with the Process Monitor logs. ProcDOT’s infection evolution animation capabilities also eradicates the downside of older graphing techniques lacking the ability to effectively visualize the aspect of time.

Christian’s road map (future think) for ProdDOT includes:

·         Export capabilities for the graph

·         Consider and provide much more information of PCAP data

·         Time and context-dependent ranges of frames/events

·         Customizable color themes

·         Notes and tags

·         Better GUI support of filters

·         Session related filters

This is a tremendous project and I look forward to its long life with ongoing support. As we run it through its paces I am quite certain you’ll come to the same conclusion.

ProcDOT Preparation

Christian has provided good documentation, including some easily avoided pain points that are worthy of repeating here. Process Monitor’s configuration needs to be tuned to ensure ProcDOT compatibility.

In Process Monitor:

·         Under Options, disable (uncheck) "Show Resolved Network Addresses"

·         Via Options à Select Columns, adjust the displayed columns

o   To not show the "Sequence Number" column

o   To show the "Thread ID" column

Figure 1 exemplifies the correct Process Monitor configuration.

Figure 1: Process Monitor configuration to support ProcDOT

ProcDOT also needs to know where its third party tool dependencies are fulfilled.

In ProcDOT, under Options:

·         Choose your Windump/Tcpdump executable as a fully qualified path

·         Choose your Dot executable (dot.exe) as fully qualified path

Figure 2 shows my ProcDOT configuration as enabled on a 64-bit Windows 8 analysis workstation running the 64-bit version of ProcDOT. Keep in mind that the ProcDOT project releases a version that runs on Linux as well.

Figure 2: ProcDOT tool path configuration

ProcDOT visualization

I worked with a couple of different samples to give you a sense of how useful ProcDOT can be during runtime analysis. I started with a well detected Trojan dropper (Trojan/Win32.Qhost) from a threat-listed URL courtesy of Scumware.org, “just another free alternative for security and malware researchers,” to trace interesting behavior when executing 3DxSpeedDemo.exe on a victim system. The MD5 for this sample is 20928ad520e86497ec44e1c18a9c152e if you’d like to go get it for yourself. Alternatively, if you’d like to avoid playing with malware and just want the Process Monitor CSV and related PCAP, ping me via email or Twitter and I’ll send them to you. I ran the malicious binaries on a 32-bit Windows XP SP3 virtual machine, capturing the related Process Monitor CSV log and the PCAP taken with Wireshark, then resetting to a clean snapshot for each subsequent analysis. You need to ensure that you save your default Process Monitor .PML file to .CSV which is easily done by selecting Save, choosing All Events and the CSV format. I copied the .PCAP and .CSV files from each run to my workstation and created visualizations for each.

Loading ProcDOT and readying it for a visualization run is simple. In the UI, select the appropriate CSV from Procmon-CSV field and PCAP from the Windump-File field. Note that the selection window for Windump-File defaults to Windump-TXT (*.txt); simply switch to Windump-PCAP (*.pcap) unless you actually generated text results. Check the no paths and compressed boxes, and hit Refresh.

This will generate an interactive graph, but you won’t yet see results. You now must select the Launcher, ProcDOT will analyze the Process Monitor file, then ask you to select the first relevant process. This is typically the malicious executable (double-click it) you executed on your virtual machine or intentionally compromised system; again, 3DxSpeedDemo.exe for my first run, as seen in Figure 3.

Figure 3: ProcDOT malicious process selection

Hit Refresh one more time and voila, your first visualization.

A few ProcDOT navigation tips:

1)      Hold CTRL and roll the scroll wheel on your mouse to zoom in and out.

2)      Hold your left mouse button while hovered over the graph to move it around in the UI.

3)      Double-click an entity to zoom in on it.

4)      Right-click an entity for details. Hit ESC to remove the highlighting.

At the bottom of the UI if you click the film click, ProcDOT will move into playback mode and step through each process as they were captured. Remember our mention above of infection evolution animation capabilities that give you the ability to effectively visualize the aspect of time? Bingo.

Check out the Legend under help (?) for the breakdown on the symbols used in graphing.

As I played back the Win32.Qhost infection, Frame 91 jumped out at me where Thread 1168 of the cmd.exe process (PID 1828) wrote data to the hosts file as seen in Figure 4.

Figure 4: ProcDOT captures Win32.Qhost writing to the hosts file

Oh snap! I love malware that does this. I jumped back to my malware VM, re-executed the malware, and captured the hosts file from C:\Windows\System32\Drivers\etc.

Figure 5 gives you an immediate sense of who the players are in this little vignette.

Figure 5: You want me to login where?

The IP address 91.223.89.142 is indeed in the Russian Federation but is not the appropriate A record for odnoklassniki.ru, or mail.ru, or vk.com, or ok.ru…you get the idea. I find it ironic that a seemingly Russian perpetrator is targeting Russian users as Eastern Bloc cybercriminals favor spreading their little bits of joy beyond their own borders. Just sayin’.

The Zbot sample I analyzed (MD5: 58050bde460533ba99d0f7d04eb2c80a) made for great network behavior analysis with ProcDOT. I can’t possibly capture all the glorious screen real estate here, but Figure 6 should give you an idea of all the connections spawned by explorer.exe.

Figure 6: ProcDOT network analysis

So many avenues to explore, so little time. Take the time, it’s a rabbit hole you definitely want to go down. There’s so much value in ProcDOT for malware analysts, incident responders, and forensicators. Paint a picture, cut to the quick, “the bounties of the past, present and future” await you in a “stunning data blur” created by ProcDOT. See Figure 7 for enough proof to motivate you to explore on your own.

Figure 7: A stunning data blur…

In Conclusion

We’ve covered some truly kick@$$ tools already this year; Violent Python, SET, Redline, and Recon-ng put ProcDOT in some major company, but if I were able to vote for Toolsmith Tool of the Year in 2013, ProcDOT would be right at the top of my list. The current release is a still an RC, if you find any bugs let Christian know. The roadmap is solid so I am really looking forward to the stable releases soon to come. In particular, export capabilities for the graph will be a big step. Again, sample CSVs and PCAPs are available on demand.

Ping me via email if you have questions or suggestions for topic via russ at holisticinfosec dot org or hit me on Twitter @holisticinfosec.

Cheers…until next month.

---

[1] Dorris, J. (2013, MAY 27). Robots, rebooted. electro-pop duo daft punk's triumphant new record. Time,181(20), 60.

toolsmith: Recon-ng

Prerequisites/dependencies

Python interpreter-enabled system, Kali Linux utilized for this review

Introduction

The community of tools and developers converges again this month as we explore Tim Tomes’ Recon-ng. Jeremy Druin, whose NOWASP Mutillidae we explored in August 2012’s toolsmith, introduced me to Tim, having recognized another great tool worthy of exploration and sharing with toolsmith nation. Recon-ng is optimized for use during the reconnaissance phase of web application penetration testing. You’ll note convergence again given that we described managing web application penetration testing phases in last month’s toolsmith regarding Redmine. Tim says it best on his Recon-ng site: “Recon-ng is not intended to compete with existing frameworks, as it is designed exclusively for web-based open source reconnaissance. If you want to exploit, use the Metasploit Framework. If you want to Social Engineer, us the Social Engineer Toolkit. If you want to conduct reconnaissance, use Recon-ng!”

More from Tim on Recon-ng, shared exclusively with toolsmith:

“Recon-ng is commonly seen as being most useful in the role of supporting Social Engineering engagements, but the real power of the framework lies in its ability to perform all steps of the traditional penetration testing methodology, except exploitation, within the context of reconnaissance. What does that mean? It means that we can do scope validation through host discovery, server enumeration, vulnerability discovery, and gain access to authentication credentials, all without sending a single packet to the target application or network. Recon-ng does this by leveraging powerful, 3rd party, web-based resources that do all of this stuff for us, and provide access to the results. It is important to keep in mind that there are caveats to this. Using 3rd parties to collect data on clients may be in direct violation of Non-Disclosure Agreements (NDA) or contracts. It is up to the tester to make sure that the client specifically approves this activity as part of the testing agreement.

While the framework is named for its focus on reconnaissance, the intent is not to limit its functionality to only recon. Python developers have been waiting a long time for a fun, easy, and useful project to contribute to. They now have that in Recon-ng. Therefore, when contributors come up with new ideas for modules that cross the boundary of reconnaissance into active discovery and exploitation, they are encouraged to submit them for review. The several discovery modules included in the framework are good examples of this.

I get asked quite often, "How does Recon-ng fit into your testing methodology?" The answer is simple. It's the first tool I use on every engagement, and often during the scoping process. Do I run every module in the framework? No. It largely depends on the type of assessment. But there are several things I always do. I always harvest hosts from Google, Shodan and IP-Neighbors and enumerate with the Resolve, BuiltWith and PunkSPIDER modules. I always harvest contacts using Jigsaw, LinkedIn, PGP and Whois, and mangle them into email addresses with the Mangle module. And I always check for compromised accounts and harvest any available credentials using the various PwnedList modules.”

We’ve provided much detail on the web application penetration testing methodology as describe by SANS in earlier toolsmiths, so in order to broaden our horizons a bit, I’ll plug Recon-ng use into the various phases of the OWASP Testing Guide v4. Version 4 is the draft version, version 3 (2008) is considered stable. The Information Gathering section of the guide is a ten-part contribution to Section 4 of the guide, Web Application Penetration Testing. Immediately relevant steps from the draft TOC include:

·         4.2.1 Testing for Web Server Fingerprint (OWASP-IG-004)

·         4.2.2 Review Webserver Metafiles (OWASP-IG-001)

·         4.2.5 Identify application entry points (OWASP-IG-003)

We’ll also use reconnaissance methods to lend to section 4.4.2 Testing for User Enumeration and Guessable User Account (OWASP-AT-002) from 4.4 Authentication Testing.

We’ll use Recon-ng to realize the goals of a few of these OWASP Testing Guide steps as we explore further below.

Recon-ng Installation

Recon-ng installs with ease on any Python and Git enabled system. On Kali, running as root, it’s as simple as:

git clone https://LaNMaSteR53@bitbucket.org/LaNMaSteR53/recon-ng.git

cd recon-ng

./recon-ng.py

Figure 1 represents the initiated Recon-ng shell and its 57 recon, 6 discovery, 1 exploitation, and 2 reporting modules.

FIGURE 1: Getting underway with Recon-ng

The dependencies on dnspython, httplib2, and python-oauth2 are already met in the recon-ng lib directory. If you’re familiar with Metasploit you’ll be right at home with Recon-ng. Refer to the wiki for a usage overview. I worked with both the stable version 1.20, as well as the beta of 1.30, which should be a stable release by the time you read this. 1.30 includes major updates including what @LaNMaSteR53 Tweeted is a badly needed API key handling system.

Putting Recon-ng to use

A few quick use pointers may help you get under way with Recon-ng. Command completion is handy as you consider typing commands such as

use recon/contacts/enum/http/should_change_password.

Hitting tab while keying will complete based on options for command or parameter. Also extraordinarily useful is the smart load feature which allows loads modules when you refer to a keyword unique to the desired module's name. As an example, for the first module we’ll test I simply typed use xssed which loaded the recon/hosts/enum/http/web/xssed module. This works well without the full path as it is the only module containing the string xssed but if multiple modules share the same keyword you’ll receive a list of possible modules. Use is also, in reality, an alias for the load command; they work identically. Apparently, overly sensitive Metasploit users bugged Tim until created command alignment. From a Recon-ng prompt the best way to see all modules available to you is to pass the show modules command, and don’t forget to use the ? command when you need more information. As an example show ? reveals your usage options are show [modules|options|workspaces|schema|] . With a particular module loaded, use info for name, author, description, and options details. Then use set based on the options defined followed by the run command. That’s all there is to it. You can define individual workspaces or other global options as well. I ran show options then set workspace holisticinfosec for our efforts here. You can also set proxy settings here if you wish to record your sessions with the like of Burp Suite. The resulting report from Burp is a nice output product for your pentest engagements. Equally useful might be the use of an anonymizing proxy.

Use the recon/hosts/enum/http/api/builtwith module for 4.2.1 Testing for Web Server Fingerprint (OWASP-IG-004). As the guidance states “knowing the version and type of a running web server allows testers to determine known vulnerabilities and the appropriate exploits to use during testing” you can imagine why. I loaded the module, passed set host holisticinfosec.org, and followed with run, resulting in Figure 2.

FIGURE 2: Recon-ng establishes server details

For 4.2.2 Review Webserver Metafiles (OWASP-IG-001) an ideal module is discovery/info_disclosure/http/interesting_files. This is not a passive module; it will reach out and touch the defined source, and download discovered files such as robots.txt, sitemap.xml, crossdomain.xml, and phpinfo.php. The discovered and downloaded files are written to the workspace directory in which you are operating. The /recon-ng/workspace/default workspace is the default if none is specified in the global options.

The xssed module relates nicely to section 4.2.5 Identify application entry points (OWASP-IG-003) which describes the process to identify application entry points. OWASP’s brief overview of this phase states that “enumerating the application and its attack surface is a key precursor before any attack should commence. This section will help you identify and map out every area within the application that should be investigated once your enumeration and mapping phase has been completed.” Parameters vulnerable to cross-site scripting (XSS) via GET or POST requests certainly fall in the “worthy of investigation” category as variables exhibiting XSS vulnerabilities are sometime vulnerable to other issues such as SQL injection or directory traversal. Of course, XSS in and of itself represents a number of opportunities for the attacker and should be paid close attention as such.

The xssed module as written by Micah Hoffman (@WebBreacher) checks XSSed.com for XSS records for the given domain and displays the first 20 results. From the Recon-ng prompt I passed the use xssed command followed by set domain microsoft.com. Given that I work there and my attack & penetration testing may have a Microsoft domain in scope for a penetration test, this module could prove a logical first step. Note that all the returned results for this effort have been fixed even if results state otherwise.  After setting the domain parameter one need only issue a run command to kick off the module. Figure 3 shows the results.

FIGURE 3: Recon-ng XSSed module results

The result advises us that, had it not been fixed, the search parameter would have been ideal for further exploration or use in packaging XSS payloads during an exploitation phase.

Recon-ng’s LinkedIn Authenticated Contact Enumerator is a great way to gather possible social engineering or bruteforcing targets, ideal during the 4.4.2 Testing for User Enumeration and Guessable User Account (OWASP-AT-002) phase. You’ll need a LinkedIn API key; just login with you LinkedIn cred and visit the LinkedIn Developer Network. Note: a few Recon-ng modules require API keys. Keep in mind that the Pwnedlist API has a rather high cost associated with it, but if your organization has already purchased API access, you can leverage it with Recon-ng for the Pwnedlist modules account_creds, api_usage, domain_creds, domain_ispwned, leak_lookup, and leaks_dump. Tim pointed out that, as a Pwnedlist customer, he extremely fond of the domain_creds module in particular as it returns actual domain credentials. Nothing like walking in to a customer penetration testing engagement already in possession of domain creds. For the LinkedIn module run use linkedin, followed by set company , then run. No screenshot here as the module dumps lots of juicy contact data and I don’t want a bunch of folks upset with me.

Keep in mind that you can always query the native Recon-ng SQLite database with the query command followed by common SQL syntax. As an example query select * from hosts returns data populated in the columns host, ip_address, region, country, latitude, and longitude during module runs. The database schema is included in Figure 4.

FIGURE 4: Recon-ng database schema

Finally, you will definitely want to take advantage of the reporting modules.

Tim mentioned that the reporting/csv_file module is great for importing into Excel then massaging the data while reporting/html_report module is optimal for producing reports for customers. Figure 5 shows my reporting run against all date I’d written so for the db.

FIGURE 5: Recon-ng database schema

There are, as is often the case with great toolsmith topics, too many features and killer use case scenarios to cover here. I even suggested to Tim he write the Recon-ng book. Yes, I think it’s that good.

In Conclusion

I’m really excited about Recon-ng and wish Tim great success. My two favorite phases are reconnaissance and exploitation and Recon-ng fits the bill to dominate the first and contribute greatly to the second. Setting it up and getting started is a sixty second proposition and leaves you no room for excuses. Get cracking with this tool STAT, run it against entities specific to your organizations, and immediately benefit. Or there’s always the alternative of waiting and having the hackers do it for you.

Ping me via email if you have questions or suggestions for topic via russ at holisticinfosec dot org or hit me on Twitter @holisticinfosec.

Cheers…until next month.

toolsmith: Implementing Redmine for Secure Project Management

Prerequisites/dependencies

VMWare for this methodology or a dedicated installation platform if installed from ISO

Introduction

From Redline for March’s toolsmith to Redmine for April’s, we’ll change pace from hacker space to the realm of secure project management. Following is a shortened version of a much longer Redmine study written for the SANS Reading Room as part of graduate school requirements and released jointly with ISSA.

Security and collaborative project management should not be exclusive. Software designed to support secure project management and security-oriented projects can be both feature rich and hardened against attacks. Web applications such as Redmine offer just such a solution and can embrace the needs of project managers and security practitioners alike. Redmine is project management and bug tracking software built on Ruby on Rails with a focus on collaboration, functionality, and when enhanced with specific plugins, can be configured securely to facilitate security-oriented projects. As a productivity platform, Redmine allows convenient team workflow while embracing the needs of virtual or mobile project members with a focus on socially oriented processes. We’ll explore the secure implementation and configuration of a Redmine server, and then transition into step-by-step details for managing a real world web application penetration testing project using Redmine. This will include the distribution of a virtual machine ready-built for real world use during such projects, pre-configured with a project template based on workflow in the SANS 542 Web Application Penetration Testing course.

From the TurnKey Redmine Web page: “Redmine is a Rails web application that provides integrated project management features, issue tracking, and support for multiple version control programs. It includes calendar and Gantt charts to aid visual representation of projects and their deadlines. It also features multi-project support, role based access control, a per-project wiki, and project forums”. Additionally, a tool such as Redmine allows the convergence of software and security testing. As a software configuration management (SCM) tool, Redmine is ideally suited to projects related to software development. That said, the security expertise required to security test software needs equal consideration and project management. “Sometimes security, or pen-testers for short - work on the same test team as functionality testers; other times, pen-testers work as security consultants and are hired by the software development company to perform security tests”[1]. Regardless of who solicits the use of pen-testers, the related pen-test is a project, and Redmine is the ideal application to provide the agile, flexible platform pen-testers need to coordinate their efforts with the help of a PM or team lead.

Installation

Redmine installation and configuration using a TurnKey Linux Redmine appliance built on a Debian-based Linux distribution, is reasonably straightforward. Your ability to install a Linux operating system from an ISO file on a dedicated machine, or configuring a VMware virtual machine is assumed. It is also assumed you have control of or access to an Active Directory domain for LDAP authentication to Redmine, as it allows for more robust user management. As referenced later, the IP address of the Redmine instance was 192.168.248.16 and 192.168.248.248 for the domain controller. The stable version of the TurnKey virtual Redmine appliance (version 12) running on a lean instance of Debian Squeeze (CLI only, no X11 GUI) via VMWare Workstation 9 was utilized for this research. Note, readers will find running the shell via Putty or a client where you can cut and paste installation strings easier as the VMWare tools aren’t effective without the GUI. This TurnKey Redmine appliance relies on Passenger, a module for Apache that hosts Ruby on Rails applications, and supports the use of SSL/TLS (configured by default) and ModSecurity for better security.

As of this writing the current version of Redmine was 2.2.1 and will be described herein. The installed version of Redmine on the TurnKey appliance is 1.4.4; this guidance will include its upgrade to Redmine 2.2.1.

First, download the Turnkey Linux VM appliance and open it in VMWare.  The first boot routine will ask you to create passwords for the root account, the MySQL root user, and the Redmine admin. When the routine completes you should be presented the TurnKey Linux Configuration Console as seen in Figure 1.

FIGURE 1: TurnKey Linux Configuration Console

In the Hardening section, the process of disabling the services you don’t intend to use will be discussed. Take a snapshot of the virtual machine at this point and name the snapshot Base Install.

Update the Redmine version from a command prompt on the Redmine server as follows:

1.                   apt-get update

2.                   apt-get upgrade

3.                   apt-get install locate

4.                   updatedb

5.                   cd /var/www

6.                   mv redmine redmine -old

7.                   hg clone --updaterev 2.0-stable https://bitbucket.org/redmine/redmine-all redmine

8.                   cp redmine -old/config/database.yml redmine/config/database.yml

9.                   cp -r redmine-old/files/ redmine/files/

10.               chown -R root:www-data /var/www/ redmine

11.               cd redmine

12.               gem install bundler

13.               gem install test-unit

14.               bundle install --without development test rmagick

15.               mkdir public/plugin_assets

16.               rake generate_secret_token

17.               rake db:migrate RAILS_ENV=production

18.               chown -R www-data:www-data files log tmp public/plugin_assets

19.               rake redmine:plugins:migrate RAILS_ENV=production

20.               chmod -R 755 files log/ tmp/ public/plugin_assets

21.               rake tmp:cache:clear

22.               rake tmp:sessions:clear

Run the script /var/www/redmine/script/about to confirm the version upgrade.

LDAP authentication is inherent to Redmine but requires a bit of setup. The example Active Directory domain name utilized via a virtual Windows Server 2008 domain controller was REDMINE. The user redminer was established as the service-like account utilized by Redmine to access the directory. Do not user a domain administrator account for this user. Should your Redmine instance be compromised so too then would be your domain. Via your browser, as the Redmine admin user, navigate to Administration then LDAP Authentication. Refer to the Redmine LDAP Authentication page via the Redmine WIKI but refer to the following example configuration as successfully utilized for this research seen in Figure 2.

FIGURE 2: LDAP Configuration

Select Save then, assuming a correct configuration, you should receive indication of a successful connection when you click Test on the resulting Authentication Modes page.

Refer to the SANS Reading Room version regarding additional installation and hardening steps and don’t skip! These are important:

·         Installation

o   Pixel Cookers theme for a streamlined, tech-centric look as well as the

o   Email settings

o   Plugin installation (Ldap Sync, Scrum2B, Screenshot, Monitoring & Controlling)

·         Hardening

o   Disable unnecessary services

o   Tighten down SSH

o   Restrict Redmine web access to HTTPS only

o   Implement UFW (the uncomplicated firewall)

Engaging With Redmine

Following is a step by step description of a penetration testing engagement where Redmine is utilized to provide project support for a team of three.

The first and most important steps to undertake are the elimination of all unwanted permissions for the Non member and Anonymous roles. Login to Redmine as the admin user and select Administration | Roles and permissions | Non member | Uncheck all | Save. Repeat this process for the Anonyomous roles. These steps will ensure that you don’t inadvertently expose project data to those who don’t have explicit permission to view it. Next, to add users for this project, select Administration | Groups to add a group called PenTesters.  From Administration | Users add three users with appropriately defined login names pentester1 (Fred), pentester2 (Wilma), pentester3 (Barney), and pentestpm (BamBam) and add them to the PenTesters group. Remember these users need to also have been created in the domain you’re utilizing for LDAP authentication. Via the Administration menu, under Projects, create a project called Web Application Pentest. The activities related to this project are drawn directly from tasks outlined in the SANS 542: Web App Penetration Testing and Ethical Hacking course as well as the Samurai Web Testing Framework. Select all Modules and Trackers for the project. You’ll note that Monitoring and Controlling by Project and Scrum2b are available as implemented during the installation phase described earlier. These plugins will be described in more detail as their use is inherent to agile project management for projects such as penetration testing.

Redmine allows the creation of subprojects as well; the Web Application Pentest project should be divided into four subprojects named as follows: 1-Recon, 2-Mapping, 3-Discovery, and 4-Exploitation. Add each of them from Redmine Web Application Pentest project page and remember to enable all Modules and Trackers.

Add the user accounts for the three penetration testers and the project PM user as project and subproject members via the Members tab as seen in Figure 3.

FIGURE 3: Pen-test Project Members

Return to the project overview, select 1-Recon under subprojects, and add a new issue. File a bug for each recon phase task you’d like completed, with the applicable start and due dates. You can upload related files, screenshots (thanks to the plugin installed earlier), and designate an assignee, as well as watchers.

Under Settings for each project or subproject you define you can establish issue categories. This is an ideal method by which to establish penetration testing activities for each subproject. As an example, the recon phase of a web application penetration test includes general recon along with DNS and Whois lookups, search engine analysis, social network analysis, and location analysis. Establishing each of these as issues categories will then allow bugs (tasks) to be filed specific to each category. Each bug can in turn be assigned a pen-tester with start and end dates, along with files that might be useful to complete the task. Location analysis could include gleaning location data from victim Tweets as described in Violent Python[2]. Twitter provides an API to developers which allows information gathering about individuals (potential penetration test targets). A script from Violent Python to help in this information gathering can be uploaded into the Redmine bug, Location data from Tweets as seen in Figure 4.

FIGURE 4: Bug (task) assigned to Fred, with helper code

As bugs are added, assigned, and/or updated, if configured to communicate verbosely, Redmine will email notices to the appropriate parties. The email as seen in Figure 5 was received as a function of filing the bug in Figure 4.

FIGURE 5: Email notice for bug (task) filed

This allows real-time communication among penetration testers or any project participants defined in your Redmine deployment. As pen-testers generate findings, they can be uploaded to the associated bug, and if versioning is required, managed via the Mercurial SCM offering as described during installation.

Bug status can be tracked as New, In Progress, Resolved, Feedback, and Closed or Rejected, and each bug can be assigned a priority and estimated time. As completed, actual time spent on each bug can be tracked too. Overall project time allotments as defined in the bug then track quite nicely via the Redmine Gantt functionality as seen in Figure 6.

FIGURE 6: Redmine Gantt functionality

Scrum2b

The concept of agile software development has, over time, been applied directly to project management. Consider the use of Scrum methodology as part of agile project management. According to Agile Project Management with Scrum, “the heart of Scrum lies in the iteration. The team takes a look at the requirements, considers the available technology, and evaluates its own skills and capabilities. It then collectively determines how to build the functionality, modifying its approach daily as it encounters new complexities, difficulties, and surprises. The team figures out what needs to be done and selects the best way to do it. This creative process is the heart of the Scrum’s productivity”[3]. These creative processes, assessment of capabilities, and changing complexities and surprises are also inherent to any penetration test and as such, the agile project management framework is an ideal way to coordinate pen-test projects. The Scrum2b plugin for Redmine is well suited to answer this calling. If each phase of the pen-test is considered a sprint as defined by the Scrum process, the planning and awareness necessary to support the sprint is essential. The Scrum2b interface is a virtual Scrum Board that allows project participants to track activities by bug and members while editing the bug on the fly with the appropriate permission. The pentestpm user, as project manager, could adjust task’s percentage of completion right from Scrum2b using the time slider.

FIGURE 7: Scrum2b Scrum Board for pen-testers

If the assignee needs to jump right to the bug, the plugin is fully hyperlink enabled. The Scrum Board allows filtering the view by members and issues. New issues can also be added right from the Scrum Board.

Monitoring & Controlling

All projects require the right balance of monitoring and controlling, and penetration tests are no exception. The Monitoring and Controlling Project Work process includes “gathering, recording, and documenting project information that provides project status, measurements of progress, and forecasting to update cost and schedule information that is reported to stakeholders, project team members, management, and others”[4]. The Monitoring & Controlling plugin for Redmine shines in this capacity. Established as a convenient left-pane menu item with the Pixel Cookers theme, this plugin creates a dashboard for project data organized by Tasks Management, Time Management, and Human Resource Management. Tasks Management tracks Tasks by Status, Tasks by Category, and Task Management (manageability). Applied again to the context of a pen-test project, Figure 8 represents the Recon phase of a pen-test.

FIGURE 8: Monitoring & Controlling Tasks Management

Refer again to the SANS Reading Room version, page 17, for more regarding Time & Human Resources Management with the Redmine Monitoring & Controlling plugin.

In Conclusion

Project management includes a certain amount of tedium, but Redmine configured with the aforementioned plugins allows for a refreshing, dynamic approach to the overall secure project management lifecycle. While no system is ever absolutely secure (a serious Ruby on Rails SQL injection flaw was disclosed as this paper was written), the appropriate hardening steps can help ensure enhanced protection. Steady maintenance and diligence will also serve you well. The convenience of an implementation such as TurnKey Redmine makes keeping the entire system up to date quite easy.

A version of a TurnKey Redmine virtual machine as discussed here will be made available to readers via the HolisticInfoSec Skydrive. This instance will include a web application project template, with predefined subprojects, issue categories and bugs, again as defined in the SANS 542 course. Readers will need only create users, assign dates and members, and establish access to an LDAP service.

Ping me via email if you have questions or suggestions for topic via russ at holisticinfosec dot org or hit me on Twitter @holisticinfosec.

Cheers…until next month.

References

---

[1] Gallagher, Jeffries, and Landauer (2006). Hunting Security Bugs, Redmond, WA: Microsoft Press.

[2] O'Connor, T. (2013). Violent python. (p. 229). Walthm, MA: Syngress.

[3] Schwaber, K. (2004). Agile project management with scrum.

[4] Heldman, K. (2009). Pmp: Project management professional exam study guide. (Fifth ed.). Indianapolis, IN: Sybex.