An SPF DNS Server

2020-07-16

The Sender Policy Framework is one of those things that’s really powerful and useful to help prevent phishing and email spam, but can be a royal pain to work with. Specifically, SPF is a series of DNS TXT records¹ with a specific format that can be looked up by any email service to verify that an email was sent by a server that should be authorized to send email on your behalf. For example

"v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all"

v=spf1 - tells the client this is an SPF record and should always start the record
{key}[:{value}]? - one of many different key/value pairs that can define the record
- in the case above a ip4 key species an IPv4 address range that can send emails on your behalf (the value can be optional)
- the a above is another special case where if the sender domain ([email protected] would be example.com) resolves via a DNS A record to the server that sent the email, it’s allows
-all is a fallthrough case meaning ‘fail all that didn’t match a previous case

There are a number of other cases, but we’ll get to the other interesting ones in a bit.

SSRF Protection in Rails

2020-06-30

One of the more subtle bugs that a lot of companies miss is Server Side Request Forgery (SSRF). Like it’s cousin CSRF (cross-site request forgery), SSRF involves carefully crafting a request that runs in a way that the original developers didn’t expect to do things that shouldn’t be done. In the case of CSRF, one site is making a request on behalf of another in a user’s browser (cross-site), but in SSRF, a request is being made by a server on behalf of a client, but you can trick it into making a request that wasn’t intended.

For a perhaps more obvious example, consider a website with a service that will render webpages as preview images–consider sharing links on a social network. A user makes a request such as /render?url=https://www.google.com. This goes to the server, which will then fetch https://www.google.com, render the page to a screenshot, and then return that as a thumbnail.

This seems like rather useful functionality, but what if instead, the user gives the url: /render?url=https://secret-internal-site.company.com. Normally, company.com would be an internal only domain that cannot be viewed by users, but in this case–the server is within the corporate network. Off the server goes, helpfully taking and returning a screenshot. Another option–if you’re hosted on AWS–is the AWS metadata endpoint: http://169.254.169.254/latest/meta-data/. All sorts of interesting private things there. Or even more insidious, /render?url=file:///etc/password. That shouldn’t work in most cases, since most libraries know better than to rener file:// protocol URLs, but… not always!

Creating a temporary SMTP server to 'catch' domain validation emails

2018-07-09

One problem that has come up a time or two is dealing with email-based domain validation (specifically in this case for the issuance of TLS certificates) on domains that aren’t actually configured to receive email. Yes, in a perfect world, it would be easier to switch to DNS-based validation (since we have to have control of the DNS for the domain, we need it later), but let’s just assume that’s not an option. So, how do we ‘catch’ the activation email so we can prove we can receive email on that domain?

Generating zone files from Route53

2018-03-12

Recently I found myself wanting to do some analysis on all of our DNS entires stored in AWS’s Route53 for security reasons (specifically to prevent subdomain takeover attacks, I’ll probably write that up soon). In doing so, I realized that while Route53 has the ability to import a zone file, it’s not possible to export one.

To some extent, this makes sense. Since Route53 supports ALIAS records (which can automatically determine their values based on other AWS products, such as an ELB changing its public IP) and those aren’t actually ‘real’ DNS entries, things will get confused. But I don’t currently intend to re-import these zone files, just use them. So let’s see what we can do.

Large scale asynchronous DNS scans

2013-09-27

On Monday we laid out a framework for converting structures into bytes. On Wednesday, we used that to enhance Racket’s UDP and DNS capabilities. Today, we’re going to take that all one step further and scan large portions of the Internet. The end goal will be to look for DNS-based on a worldwide scale.

Extending Racket's DNS capabilities

2013-09-25

As I mentioned on Monday, I wrote my DNS-based censorship around the world–and to do that, I need a fair bit of control over the DNS packets that I’m sending back and over parsing the ones that I get back.

ISMA 2013 AIMS-5 - DNS Based Censorship

2013-02-09

I gave a presentation about research that I’m just starting out studying DNS-based censorship in specific around the world. In particularly, preliminary findings in China have confirmed that the Great Firewall is responding via packet injection to many queries for either Facebook or Twitter (among others). Interestingly, the pool of IPs that they return is consistent yet none of the IPs seem to resolve to anything interesting. In addition, there is fallout in South Korea where some percentage of packets go through China and thus have the same behaviors.

AIMS-5 - Day 3

2013-02-09

Yesterday was the third and final day of AIMS-5. With the main topic being Detection of Censorship, Filtering, and Outages, many of these talks were much more in line with what I know and what I’m working on. I gave my presentation as well, you can see it (along with a link to my slides) down below.

AIMS-5 - Day 2

2013-02-08

Today’s agenda had discussions on Mobile Measurements and IPv6 Annotations, none of which are areas that I find myself particularly interested in. Still, I did learn a few things.

AIMS-5 - Workshop on Active Internet Measurements

2013-02-07

Yesterday was the first of three days for the fifth annual ISC/CAIDA Workshop I went to in Baltimore back in October at least, but even the ones that weren’t have still been interesting.

I’ll be presenting on Friday and I’ll share my slides when I get that far (they aren’t actually finished yet). I’ll be talking about new work that I’m just getting off the ground focusing specifically on DNS-based censorship. There is a lot of interesting ground to cover there and this should be only the first in a series of updates about that work (I hope).