mattkeeley / spoofy Goto Github PK

Spoofy is a program that checks if a list of domains can be spoofed based on SPF and DMARC records.

License: Creative Commons Zero v1.0 Universal

Python 100.00%

application-security appsec cybersecurity deliverability dmarc email-security emails infosec penetration-testing penetration-testing-tools

spoofy's Introduction

Spoofy

WHAT

Spoofy is a program that checks if a list of domains can be spoofed based on SPF and DMARC records. You may be asking, "Why do we need another tool that can check if a domain can be spoofed?"

Well, Spoofy is different and here is why:

Authoritative lookups on all lookups with known fallback (Cloudflare DNS)

Accurate bulk lookups

Custom, manually tested spoof logic (No guessing or speculating, real world test results)

SPF lookup counter

PASSING TESTS

HOW TO USE

Spoofy requires Python 3+. Python 2 is not supported. Usage is shown below:

Usage:
    ./spoofy.py -d [DOMAIN] -o [stdout or xls]
    OR
    ./spoofy.py -iL [DOMAIN_LIST] -o [stdout or xls]
    
Install Dependencies:
    pip3 install -r requirements.txt

HOW DO YOU KNOW ITS SPOOFABLE

(The spoofability table lists every combination of SPF and DMARC configurations that impact deliverability to the inbox, except for DKIM modifiers.) Download Here

METHODOLOGY

The creation of the spoofability table involved listing every relevant SPF and DMARC configuration, combining them, and then conducting SPF and DMARC information collection using an early version of Spoofy on a large number of US government domains. Testing if an SPF and DMARC combination was spoofable or not was done using the email security pentesting suite at emailspooftest using Microsoft 365. However, the initial testing was conducted using Protonmail and Gmail, but these services were found to utilize reverse lookup checks that affected the results, particularly for subdomain spoof testing. As a result, Microsoft 365 was used for the testing, as it offered greater control over the handling of mail.

After the initial testing using Microsoft 365, some combinations were retested using Protonmail and Gmail due to the differences in their handling of banners in emails. Protonmail and Gmail can place spoofed mail in the inbox with a banner or in spam without a banner, leading to some SPF and DMARC combinations being reported as "Mailbox Dependent" when using Spoofy. In contrast, Microsoft 365 places both conditions in spam. The testing and data collection process took several days to complete, after which a good master table was compiled and used as the basis for the Spoofy spoofability logic.

DISCLAIMER

This tool is only for testing and academic purposes and can only be used where strict consent has been given. Do not use it for illegal purposes! It is the end user’s responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this tool and software.

CREDIT

Lead / Only programmer & spoofability logic comprehension upgrades & lookup resiliency system / fix (main issue with other tools) & multithreading & feature additions: Matt Keeley

DMARC, SPF, DNS insights & Spoofability table creation/confirmation/testing & application accuracy/quality assurance: calamity.email / eman-ekaf

Logo: cobracode

Tool was inspired by Bishop Fox's project called spoofcheck.

LICENSE

This project is licensed under the Creative Commons Zero v1.0 Universal - see the LICENSE file for details

spoofy's People

Contributors

Stargazers

Watchers

spoofy's Issues

DKIM Collection/Analysis

Love the tool! Have we considered adding DKIM support as well? There is research out there on bypassing DKIM requirements and it would be nice to have a single tool to identify and evaluate the DKIM record? My previous coworker had wrote some code here on how guessing common DKIM subdomains that may be helpful:

https://github.com/Nakul08/MailRecords

Some example of DKIM attacks:

Discuss the logic in is_spoofable

Some conditions in is_spoofable look weird, but I'm not sure if it's intended or not. I'm not an expert in email security, so the recommendations might not be correct, just want to know if these conditions make sense.

Line 49: p == "none" and sp == "reject" or sp == "quarentine"
- Should it be p == "none" and (sp == "reject" or sp == "quarentine") ?
Line 62 and Line 64
- 62: (p == "reject" or p == "quarentine") and aspf and sp == "none"
- 64: (p == "reject" or p == "quarentine") and aspf is None and sp == "none"
- These two cases return the same value (6), and the only difference is that whether the aspf is None or not, which also indicates that aspf can be ignored in this case. Maybe checking (p == "reject" or p == "quarentine") and sp == "none" is enough for this two cases
Line 70 and 72
- 70: p == "none" and aspf == "s" or None and sp == "none"
- 72: p == "none" and aspf == "s" or None and sp is None
- These two cases have similar situations. Perhaps aspf == "s" or None should be (aspf == "s" or aspf is None)

Multipart domain

I live in New Zealand where we have multipart domain names e.g. mydomain.co.nz. This kind of domain fails in the get_dmarc_record and get_dmarc_org_policy functions.
If I do something like:
def get_dmarc_record(domain):
if domain.endswith(".com") & domain.count('.') > 1: return get_dmarc_org_policy(domain)
or
def get_dmarc_record(domain):
if domain.find(".co.") < 1 & domain.count('.') > 1: return get_dmarc_org_policy(domain)
Then my domains work. The complication is that you have heaps of other top-level domains now, so using just ".com" isn't a solution:
.biz
.kiwi
.co
Also, there are a few places similar to Australia who use mydomain.com.au which will also cause issues.
I'm not good enough with Python to offer a robust solution for this, but I'm sure there is a way.

Parsing TXT Records incorrectly

Description

If a TXT record is resolved with greater than 256 characters. The script replaces the " to concatenate the second TXT record.
Example if something like this appears "-al" "l" in seperated TXT records because of length the script does not recognize the setting, as it parses it from -al" "l" to -al l". This can be quickly fixed, we see this error with our own company domain.

I don't want to put in our explicit example from the logs, to not expose any details here on github.
I fixed this already in my local cloned version of you script, however I would like to address this as it may create false-positives for others.

Current Code

                spf_record = str(dns_data).replace('"','')

Code Change

                spf_record = str(dns_data).replace('" "','')

This will handle the concatenation correctly and makes "-al l" to "-all" and also of course any other strings that are split on the TXT size limit. :)