Applied ThreadFix®: Seeding Your Application Portfolio with OWASP Amass

OWASP Amass is a great tool for asset discovery and enterprise attack surface mapping. It pulls data from a number of different data sources and identifies potential hosts and applications associated with organizations, domains, IP CIDRs and other identifiers. As we have noted, having a solid Application asset portfolio is table stakes for any credible application security program, so this post will look at ways to use OWASP Amass to help craft that application asset portfolio.

OWASP Amass Basics

Others have done a tremendous job of providing background on the OWASP Amass tool and how to use it. Please take a look at these resources to familiarize yourself before going forward:

• OWASP Amass GitHub page
• Hakluke’s Guide to Amass on Medium
• OWASP Amass tutorial from Daniel Miessler
• OWASP Amass tutorial on GitHub

OWASP Amass and ThreadFix

So how does it make sense to use OWASP Amass with the ThreadFix platform? As noted previously, ThreadFix allows you to track an arbitrary number of Application assets, regardless of your license. This means that you can feed ThreadFix new Application asset data from OWASP Amass at will without concerns about running up against licensing limits. Your organization’s Application portfolio and attack surface is growing and changing all the time, so it makes sense to periodically run OWASP Amass to detect any changes (additions) in your attack surface, and get those fed to ThreadFix so that they can be tracked and ultimately included in your vulnerability management program.

To demonstrate how this could work, we put together a couple of simple scripts. They are available from the threadfix-examples GitHub repository in the amass_to_threadfix/ directory.

The Amass folks provide an example of using their “track” capability to watch for changes in detected hosts over time toward the bottom of the tutorial mentioned above, so we modified that a bit, resulting in the amass_alert.sh bash script. This script takes a couple of file inputs:

• txt – a file containing a list of – get this – domains to monitor, with one per line. So for the various domains that your organizations owns and uses – fill out that file.
• ini – an Amass config file. The one we package is basically blank, but has a link to a thorough example file from the Amass folks.

Then we also wrote a Python wrapper script amass_to_threadfix.py that will take the results of the bash script and use those outputs to create new Applications in a “holding tank” Team in a ThreadFix server for evaluation. The progression is intended to look like:

1. Amass finds new hosts/applications
2. They get pushed to ThreadFix into a placeholder Team where an analyst knows to look for them
3. New applications that are legitimate finds get moved to the appropriate Team in ThreadFix and marked up with any appropriate metadata … or
4. Those applications get deleted or maybe tagged as not currently important so they can be ignored

That Python wrapper script takes arguments like:

Usage: amass_to_threadfix.py <tf_server> <api_key> <team>

• tf_server – the ThreadFix server you want to push the applications to (this URL will usually end in threadfix/)
• api_key – the API key you want to use to create the Applications
• team – the ThreadFix Team name that you want to use as your initial destination (the script will look up the Team ID based on the name provided)

So – if you set the amass_to_threafix.py script to run via cron on a regular basis, Amass will go out to find new hosts and applications that have appeared since the last run. Those applications will be pushed to ThreadFix, and once they are there, a security analyst can determine if the new ThreadFix Applications represent actual applications that need to be incorporated into your vulnerability management program.

Conclusion

These scripts represent a quick-and-dirty way to integrate OWASP Amass into your application portfolio management practice using ThreadFix. OWASP Amass has a lot more capabilities – what we are doing here only scratches the surface. Also, we can collect a lot more metadata about these applications and incorporate that into their entries in ThreadFix. If this is interesting – please let us know. If you are using ThreadFix and interested in some help getting a handle on your enterprise application attack surface we have a full line of implementation services available to help you get the most value from your ThreadFix deployment.

Contact us to find out more about how ThreadFix can reduce your exposure from your enterprise attack surface.